That loadable module discussion we had, could have solved a lot of memory related issues. You just load the code you need and unload it once finished. With ramdisks that could work really fast. Don't be surprised if it has a very low priority. The thread is from 2016.
Hi Roland...sorry by delay. I was involved in a really big project last year but now I'm back to business again
About your question. I hope to commit a big improvement to my framework in 1 or 2 months (July 2020).
Regards
PopolonY2k
Hi all.
I've updated PopolonY2k Framework on Sourceforge.net project repository at https://sourceforge.net/p/oldskooltech/code/HEAD/tree/msx/tr...
Some of improvements are described below:
- Memory Mapper routines added;
- Sound chip drivers complete now are written in ASM to improve latency to the first Pop!Art release;
- MSX specific routines (Hooks, machine detection, ...)
- Collections support added (Linear linked list, in future newer collection components will be added);
- SetJmp/LongJmp C-like routines added;
- Loadable module support added. Today are working with Turbo Pascal native I/O but MSXDOS2 internal I/O routines will be used to be possible using subdirectories with this module;
Please check project documentation to check the complete improvements list at project's TOC (table of content) at https://sourceforge.net/p/oldskooltech/code/HEAD/tree/msx/tr...
I'm still will be updating this repository in next weeks, adding recompiled binaries of some products I've released before, like MSXDUMP, Manifest Network Tools and finally Pop!Art VGM player (after 5 years of first videos on Facebook and Youtube), but no routines signatures will be changed, so everything is completely stable from here.
[]'s
PopolonY2k
A little late perhaps, but its an impressive upgrade. Thank you! and keep safe.
Indeed, this makes this framework really a complete extension. Hard to choose now between Fusion-C or this one
Wow, really nice to see such great work in TP, is really a great great language.
Very good job!!
Yes.....I'll be helping FreePascal team to help them with Z80 improvement support.
I think soon FreePascal will be a good alternative to SDCC.
[]'s
PopolonY2k
Hi friends. I'm planning some improvements to Framework some of these changes are described below and I would like to "hear" from you if what I'm thinking is a good path to follow.
The first thing is very basic and necessary thing that are related to bug fixes and improvements, this is needed and there's no discussion about this
The next question is about use of Turbo Pascal compiler.
Today the framework compiles since Turbo Pascal 3.0 (from Borland) to Turbo Pascal 3.3f (from MSX Computer club Enschede).
I like very much and prefer Turbo Pascal from Borland, however this Turbo Pascal version doesn`t support MSXDOS2 subdirectories on include files specification.
{i sample1.pas} (* Borland *)
{$i samples\sample1.pas} (* MSX computer club *)
I'm thinking about moving from TP3 from Borland to TP3.3f from MSX Computer club reordering framework directory structure that would be something like below:
(framework) Base directory |- (mapper) Mapper routines; |- (sound) Sound chips drivers; |- (collection) Hashmaps, linked lists, etc; |- (bios) MSX BIOS routines; |- (msxdos) MSXDOS 1/2 routines; ...........(newer packages will be added here)
So, this is the biggest change I'm planning for now (maybe moving repository to GitHub is an option too), because will be easier to organize what is Framework part from your own software part.
What do you think about this change ?
Regards
[]'s
PopolonY2k
Just for curiosity @popolony2k, does FreePacal compile in Z80?
About your change in the framework I understand that TP 3.3 included some improvements, so probably is a good solution. In C there was great project, Solid-C, but unfortunately couldn't be finished. This is not the case so, why not?
About your framework in general, did you include Kari Lamassari libraries or you decided to do them from scratch? I remember it implemented several features like memory mapper, sound libs, etc.
Thanks!
Hi Popolony2k,
Good to see you're still alive. I've read your blog and read that you modified the pascal compiler in a few ways for performance reasons. If that is correct: how about sharing that version? It looked to me like some good changes.
I feel like, you can choose which structure you prefer. The developers can then use the include's like they want. Its a comfort thing. A small change that can be considered comfort: your framework is extensive and covers a lot of functions. When you want to use your framework, you will have to dig in, read all the dependencies and experiment with the code.
If you make simple examples that show how the framework is to be used, that saves a lot of time for the developers.
I'm very interested in the further development of Freepascal as a cross-compiler for z80. Which compiler produces the most efficient code (from speed or size perspective).