Hello fellow Oric enthusiasts! I have not been able to post something so recently, but I have been working on some more example of programs using my dflat system ROM; a fast structured (integer) BASIC interpreter with inline assembler.
I thought I would share it here and also ask your opinion on a question raise by someone on Twitter. They wondered if I would be releasing the program once it has been turned in to a more complete 'game'. I will definitely, but the problem arises that this worked under the dflat ROM.
So on a real machine - what are the options? By the way dflat does not have native disk handling, only tape input/output
- I wonder is there a way to ship the entire 64K memory space as a snapshot?
- I think there is the possibility to make dflat load from disc then make itself resident in the RAM from 0xc000?
- Of course if people have the Twilighte Orix Board then they can anyway load dflat in to one of the ROM banks
Opinions welcome, and in the meantime here is a link to the work in progress..
dflat - work in progress game and deployment question
Re: dflat - work in progress game and deployment question
On disk systems (Microdisc, Jasmin, Cumulus, Cumana Reborn, ...) a possibility would be to use a loader that loads everything in main memory (possibly compressed), and when loaded replaces the top 16k of RAM with your dflat "rom" content, and then runs your game.So on a real machine - what are the options? By the way dflat does not have native disk handling, only tape input/output
- I wonder is there a way to ship the entire 64K memory space as a snapshot?
- I think there is the possibility to make dflat load from disc then make itself resident in the RAM from 0xc000?
- Of course if people have the Twilighte Orix Board then they can anyway load dflat in to one of the ROM banks
What exactly are you using in term of memory, and does the content compresses well?
Re: dflat - work in progress game and deployment question
I'll second @Dbug: All classic disk-based devices will do the job.
Else, the ORICART is exactly made for such ROM-like projects.
It's not coincidence that I used dflat as part of the first demo .
Else, the ORICART is exactly made for such ROM-like projects.
It's not coincidence that I used dflat as part of the first demo .
Re: dflat - work in progress game and deployment question
Мaybe this is the best way!Dbug wrote: ↑Fri Apr 30, 2021 3:07 pm On disk systems (Microdisc, Jasmin, Cumulus, Cumana Reborn, ...) a possibility would be to use a loader that loads everything in main memory (possibly compressed), and when loaded replaces the top 16k of RAM with your dflat "rom" content, and then runs your game.
Unfortunately, some people (like me) only have ORIC, and I will definitely need some extra device (like ORICART or else ) .
Maybe it's a good idea to have a version that can only be loaded into memory (unfortunately you will lose another 16k, but ...), and if it can't be loaded into the additional ram, to be located in the main.
I'm still interested of memory map
The game looks pretty good.
- 6502Nerd
- Pilot Officer
- Posts: 111
- Joined: Thu Oct 08, 2020 9:48 pm
- Location: Leicestershire, UK
- Contact:
Re: dflat - work in progress game and deployment question
Thank you everyone for the ideas and guidance.
I think to load dflat in to RAM would be quite a compromise - not only is the 16K ROM range not used, but as dflat needs the full 16K of space, means taking 16K away from free RAM (need to leave space for hi-res etc.). However it is an option - although I IRQ, NMI and reset vectors will go through ROM so I would need to deal with that somehow.
Looks like the best option is indeed to make a version (in addition to ROM version that can work with ORICART and ORIX) for disc which disables ROM and copies dflat to the top. I did a test compress using windows Zip and the 16K ROM comes down to around 12K. The disc version would need additional loader code to of course.
As for memory map, rax:
- page 0 to 7 is used. Bottom of memory starts 0x713 (where the first line of dflat is stored from)
- Variable space grows from top of memory which is 0x97ff
You can see then if I made a RAM version of dflat, it would need to load from 0x5800. That means free memory is 0x5800-0x0713 ~ 20K (compared to 36K).
dflat is approaching version 1.0 (I have been holding it at beta). But I think before I go to a 'release' I will need to make some option to load it without a ROM card.
I think to load dflat in to RAM would be quite a compromise - not only is the 16K ROM range not used, but as dflat needs the full 16K of space, means taking 16K away from free RAM (need to leave space for hi-res etc.). However it is an option - although I IRQ, NMI and reset vectors will go through ROM so I would need to deal with that somehow.
Looks like the best option is indeed to make a version (in addition to ROM version that can work with ORICART and ORIX) for disc which disables ROM and copies dflat to the top. I did a test compress using windows Zip and the 16K ROM comes down to around 12K. The disc version would need additional loader code to of course.
As for memory map, rax:
- page 0 to 7 is used. Bottom of memory starts 0x713 (where the first line of dflat is stored from)
- Variable space grows from top of memory which is 0x97ff
You can see then if I made a RAM version of dflat, it would need to load from 0x5800. That means free memory is 0x5800-0x0713 ~ 20K (compared to 36K).
dflat is approaching version 1.0 (I have been holding it at beta). But I think before I go to a 'release' I will need to make some option to load it without a ROM card.