News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

How to Transfer ROMS to rom board from cpr file, for ALCON, future os,spacem etc

Started by ikonsgr, 17:30, 18 October 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ikonsgr

Hi,

I'm currently working on a 512K RAM expansion/ Rom board for Amstrad cpc 464/6128.
So far, i've managed to use RAM as Rom board by placing individual 16K ROM binary files (loaded from usb flash drive using USIfAC II board, which i've also designed), in various Rom slots (implemented in 512K SRAM space).
But i seem to have problems when i want to use cpr files as source for the roms. I followed this: https://www.cpcwiki.eu/index.php/Format:CPR_CPC_Plus_cartridge_file_format to decode cpr file, remove various headers, and place the raw 16k data to each slot, according to the rom number indicated in cpr file, e.g. cb00->rom 0, cb01->rom1 etc.
But, although rom data seemed to be placed correctly in each rom slot, no cpr file seemed to work. I've tried so far, ALCON2020, SpaceM, Klax, FutureOS.
Since i never involved with cpr files in the past, i've made a couple of general assumptions:
- All roms in a cpr file are always upper roms.
- Rom slot is defined ONLY by placement in the cpr file (e.g. cb00->rom 0, cb01->rom1 etc.)
Are the above assumptions correct? Although if they are, then i really can't understand why isn't working...  ???

gerald

Some assumptions are not correct  :D

The Plus cartridge is made of an up to 512KB EPROM, split in 32 16KB block :
CB00 start from EPROM address 0x00000 
CB1F start from EPROM address 0x7C000
The CPR format describe where to put block within this EPROM.


On a Plus, sll the slot are mapped as upper ROM from ROM number 0x80 = CB00 to 0x9F = CB1F

CB00 is also mapped as lower ROM 
CB01 is also mapped as upper ROM 0 (Basic)
CB03 is also mapped as upper ROM 7 (AMSDOS)

So if you want to run a CPR from your ROM extension, you need to manage the plus specific mapping : mapping from UROM 0x80 + BASIC/AMSDOS aliasing + lower ROM

ikonsgr

Well i'm a bit confused....  ::)
How can i determine if a specific rom in a cpr file, should be upper or lower or mapped/mirrored to a different rom slot?
Is there any specifc "rom mapping guide" to determine this (e.g. rom at cb00 will have to respond to upper/lower rom at slot "X", rom at cb01 should respond to upper/lower rom at slot "Y" etc), , or maybe the information is in the cpr file it self?
For example, the 1st byte of each rom should determine the ROM type ( http://cpctech.cpc-live.com/docs/manual/s158se09.pdf ) . So maybe if i read 0x80 and above at 1st rom byte, it means that this rom should be upper rom? But if it's 0-2 means it's lower rom?
For example, i checked alcon2020 and found out that all 1st bytes of all roms at places cb01-cb31 are "1" (meaning that should be lower roms?  ::) ) except rom@cb00 which is 0xF3 which is larger than 0x80=> ROM0 = upper rom? 

And why am i starting to feel that amstrad really messed up with rom mapping in plus models...  ???  :)

andycadley

The cartridge ROM slots all exist beyond what the firmware would normally scan, so the concept of Foreground/Background ROMS as per the Firmware guide doesn't really apply (except for the "special" mapping of the first 3 cartridge banks). The special mapping of these three slots is also the only place where the difference between upper/lower ROM makes any real difference.


The first slot gets mapped as ROM 0x80 and also as the Lower ROM.


The second slot gets mapped as ROM 0x81 and also as ROM 0


The third slot gets mapped as ROM 0x82 and also as ROM 7.


Every subsequent slot gets mapped from 0x83 onwards. The "special" mappings of those first three is really just a backwards compatibility function, to keep the paging consistent with the older machines.


As far as the contents of the ROMs go, the Plus hardware doesn't care at all so the first byte in any given ROM means nothing at all. Even on old CPC models this is only used to indicate to the Firmware how the ROM should be treated, but the Firmware isn't ever going to scan the additional cart ROMs (partly because it doesn't usually scan beyond ROM 0x15 but mostly because when a non-BASIC cart is inserted the Firmware isn't there at all).

ikonsgr

Thanks for  your detailed explanation andycadley!  :)
Obviously things changed with PLUS models regarding ROMs, so rules for CPC models are not valid anymore.
Now, i suppose that in theory, the "special" mappings of the first three ROMS are important only when you want to use a cartridge on CPC models that contains only upper roms e.g. original firmware must still function as lower rom, right? But is there any cartridge (cpr file) that would need to do that?
Is it right to assume that practically the 1st rom at cb00 of any cpr file, must always mapped as lower Rom, if you want to use is on CPC models?
Also does this mean that the same cb00 ROM would also respond as UPPER ROM 0? Or Upper ROM 0 must be cb01 rom?

For example, if i want to load correctly ALCON2020 to an Amstrad cpc the rules for correct respond of ROM slots (loaded from the cpr file) would be:

- Rom at cb00 should respond as lower ROM AND upper ROM 0?
- Rom at cb01 should respond as upper ROM 1
- Rom at cb02 should respond as upper ROM 2
- Rom at cb03 should respond as upper ROM 3
...........................................

or

- Rom at cb00 should respond as lower ROM ONLY
- Rom at cb01 should respond as upper ROM 0
- Rom at cb02 should respond as upper ROM 1
- Rom at cb03 should respond as upper ROM 2
.........................................

Which one is the correct approach? Having cb00 act both as lower rom and upper rom 0, or have cb00 act as lower rom only, and all subsequent roms (cb01, cb02, cb03 etc) act as Amstrad ROMS with -1 offset (cb01->rom 0, cb02->rom 1 etc)?

GUNHED

Quote from: ikonsgr on 17:30, 18 October 21
tried so far, ALCON2020, SpaceM, Klax, FutureOS.
To install FutureOS on an EPROM card it's important to recognize that the ROM numbers are fixed. The installer DSK allows to adapt the ROM numbers. Then you can burn the data on EPROMs and use it.

For the Cartridge of FutureOS the ROM numbers are also fixed. In addition it does use features of the 6128plus. So it will not run on the regular CPC6128.

Let me help if I can help any further.  :) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

abalore

Hello,

Alcon2020 and my game compilations use the ROM number range &80 - &9F
So, it needs your ROM board to translate these numbers to the range &00-&1F in order to work. That should be easy, just ignoring the most significant bit.

That said, to make Alcon2020 work you need to map the slot &00 to lower and the rest to upper. That simple.
Regards,Abalore

andycadley

Cb00 is only the Lower ROM, CB01 is Upper ROM 0 and CB02 is Upper ROM 7.


The mapping to ROM0 and ROM7 was really only intended to support the standard BASIC cartridge for running in backcompat mode. It's probably necessary for a lot of the third party cartridge conversions though (which will have copies of the system ROMs in them to make them work)


It's not impossible for a "real" Plus cart to use these mappings too, but I'd say it's unlikely. The Lower ROM mapping is more important in that regard since it is enabled and paged in when the system starts so will contain cartridge startup code. After that you can use RMR2 to map a wider selection of ROMs as the Lower ROM (and move the location of the Lower ROM should you choose)

ikonsgr

Quote from: abalore on 15:14, 19 October 21
Hello,

Alcon2020 and my game compilations use the ROM number range &80 - &9F
So, it needs your ROM board to translate these numbers to the range &00-&1F in order to work. That should be easy, just ignoring the most significant bit.

That said, to make Alcon2020 work you need to map the slot &00 to lower and the rest to upper. That simple.
Regards,Abalore
That's really straight forward!  :) Only one clarification: since cb00 should be mapped as lower rom 0, and all others (cb01, cb02 etc) as upper roms (1-31), this means that upper rom 0 is not used? Or maybe i need to map cb00 to upper rom too?

ikonsgr

Quote from: andycadley on 11:53, 20 October 21
Cb00 is only the Lower ROM, CB01 is Upper ROM 0 and CB02 is Upper ROM 7.
Ok, but since cb01 should respond to ROM 0, what about upper rom 1? Should i use cb01 too? In 2 words, should i need to "Mirror" map cb01 to upper ROM 0 AND upper ROM1 ?
Also, if i need to map cb02 to ROM7 then where should i map cb07 if it exists too?



 

ikonsgr

Quote from: GUNHED on 14:22, 19 October 21
To install FutureOS on an EPROM card it's important to recognize that the ROM numbers are fixed. The installer DSK allows to adapt the ROM numbers. Then you can burn the data on EPROMs and use it.
For the Cartridge of FutureOS the ROM numbers are also fixed. In addition it does use features of the 6128plus. So it will not run on the regular CPC6128.
Let me help if I can help any further.  :) :) :)
Well, i've tried to use the futureos cpr files but with no luck. It would be helpful if you can tell me the exact mapping of the cbxx roms in the cpr file. Something like:
cb00-> lower ROM 0,
cb01-> upper rom 0
etc

abalore

Quote from: ikonsgr on 14:12, 20 October 21
That's really straight forward!  :) Only one clarification: since cb00 should be mapped as lower rom 0, and all others (cb01, cb02 etc) as upper roms (1-31), this means that upper rom 0 is not used? Or maybe i need to map cb00 to upper rom too?
Exactly. Upper ROM 0 is not used

andycadley

Quote from: ikonsgr on 14:25, 20 October 21
Ok, but since cb01 should respond to ROM 0, what about upper rom 1? Should i use cb01 too? In 2 words, should i need to "Mirror" map cb01 to upper ROM 0 AND upper ROM1 ?
Also, if i need to map cb02 to ROM7 then where should i map cb07 if it exists too?






No, none of the other cartridge slots get mapped to the "normal" Upper ROM ranges. There will simply be no ROM in that slot unless an external ROMbox is attached.

abalore

Quote from: abalore on 15:02, 20 October 21
Exactly. Upper ROM 0 is not used
Notice that if you use all the upper ROMs and also the lower, you would need 528KB, which doesn't fit into a 512KB cartridge. There is no point to use all of them, and everything is easier if you reserve the slot 0 for the lower ROM, which is required to boot the cartridge.

ikonsgr

Quote from: abalore on 15:08, 20 October 21
Notice that if you use all the upper ROMs and also the lower, you would need 528KB, which doesn't fit into a 512KB cartridge. There is no point to use all of them, and everything is easier if you reserve the slot 0 for the lower ROM, which is required to boot the cartridge.
That's really a relief, it would be really a headache to have in use both upper and lower rom 0  :)
One (hopefully  :) ) last question: Since cb00 should be mapped as lower rom 0 (when game is loaded in CPC models) does this means that you access ROM 0 inside your code, by directly applying rom read operations at 0000-&3fff address range? Or you need first to select it using an:OUT &DF00,&80 and then access it through &0000=&3FFF address range? Or maybe you use ROM 0 only at start up, so all this is meaningless?  :)

andycadley

ROMs still have to be paged in and out in the usual fashion (or on a Plus additionally via RMR2). When the machine starts up the Lower ROM will be enabled (so code execution will start there) but ROMs can and will be switched on and off as appropriate.

abalore

Quote from: ikonsgr on 16:35, 20 October 21
That's really a relief, it would be really a headache to have in use both upper and lower rom 0  :)
One (hopefully  :) ) last question: Since cb00 should be mapped as lower rom 0 (when game is loaded in CPC models) does this means that you access ROM 0 inside your code, by directly applying rom read operations at 0000-&3fff address range? Or you need first to select it using an:OUT &DF00,&80 and then access it through &0000=&3FFF address range? Or maybe you use ROM 0 only at start up, so all this is meaningless?  :)
There is nothing like "Lower ROM 0", there is only "Lower ROM" since it's a single 16KB block. When lower ROM is enabled, you access it in the &0000-&3fff range, no further operations are required. The port &DF is only for upper ROM selection, it's nothing related to lower ROM.

ikonsgr

Quote from: abalore on 00:46, 21 October 21
There is nothing like "Lower ROM 0", there is only "Lower ROM" since it's a single 16KB block. When lower ROM is enabled, you access it in the &0000-&3fff range, no further operations are required. The port &DF is only for upper ROM selection, it's nothing related to lower ROM.
Ok,i understand that, but the "Critical" point is this:
On Amstrad CPC machines you can access BOTH lower ROM AND one of selected upper ROMs,at  the same time, using different address ranges (000-&3fff, &c000-&ffff)
Is this true for Amstrad PLUS machines too?
Or, since all plus machines, doesn't have any build-in roms,and so, you can access roms only through cartridge (using rom numbers from &80-&9f) you can have ONLY one rom enabled at any time (accessed through &0000-&3fff or &c000-&ffff)?
This is VERY CRITICAL to know, because in case of having 2 roms enabled at the same time,i need to determine "ON THE FLY" which SRAM section should accessed (obviously because upper & lower roms would be in different blocks of SRAM)!
And i suppose anything that is "plus cartridge oriented" should follow the Amstrad plus rules, right?

andycadley

The "Lower" ROM is special, it's enabled and disabled in a different way to Upper ROMs.


On the Plus, by default, the first cartridge ROM is the Lower ROM and so enabling/disabling the Lower ROM will page that in and out of the 0000-3FFF address space.


However, with the ASIC unlocked, there are additional paging options. You can change which of the first 8 pages of the cartridge is used as the Lower ROM and you can change the address at which the Lower ROM appears to be 4000-7FFF or 8000-BFFF, via RMR2 (which is also used to determine whether the ASIC registers are paged in or out).


I'd strongly recommend reading the Arnold V documentation which gives all the details on how this works.

reidrac

AFAIK the plus is like the CPC for mapping lower and higher ROMs, with extra fancy stuff by the ASIC via RMR2.

What I don't fully get is the difference between physical and logical ROM IDs. So far my experiments are limited, but seems to work the same in plus and regular CPC for a cart with 32 slots.

See: https://www.grimware.org/doku.php/documentations/devices/gatearray#rmr
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

ikonsgr

Ok,i placed all 32 roms of the alcon2020 cpr file to 512k sram (each rom is confirmed to be placed correctly) and then, reset amstrad ,and switch from RAM expansion mode, to a special ROM board mode where, all ROMS 0-31 are active and:

- Board responds to OUT &DF00,X where it ignores the 3 upper bit of 'X', and selects a 16k block of SRAM according to the 5 lower bits e.g. any &80-&9f rom, will be mapped to blocks 00-31 of SRAM (which ofcourse correspond to ROMS 0-31)

- Internal rom (both upper and lower) is completely disabled, and Board responds to any "rom read" operation, where it reads "on the fly" A15 bit and:
  - If A15=1 (upper rom read) selects Block X of sram (where X is the number previously selected using OUT &DF00,X)
  - If A15=0 (lower rom read) select Block 0 OF SRAM (which corresponds to ROM 0)

For both operations above, Amstrad is paused momentarily, but process need ~0.5uS to complete, so practically there is no speed penalty.
Let me note also, that a similar code is used for emulating a "normal" ROM board. In fact it's more complicated as you can also use OUT &EF00,x commands to:
- Enable/disable each of the 32 roms
  -Enable/disable using ROM 0 as lower rom or not
  -Map a (selectable) different rom (saved at SRAM) when upper ROM 0 is selected and have lower rom enabled.
I've succesfully use this code to load Firmware 3.15 at lower rom 0 (block 0 on sram) , french Basic 1.1 at upper rom 0 (Block 1 on sram, which is also selected when upper rom 0 is enabled) ,along with a couple of rom games in various upper roms. Everything worked fine, after reset, i got FW 3.15 with Basic and i can use RSX commands to load games from it!
So, although the code seems to work fine (even in the most "complicated" situations when both upper and lower roms are enabled), unfortunately alcon still is NOT working...  :(
Also, i've noticed a couple of very strange things when i've tried to load alcon:
- immediately after reset, the tape relay starts to switch on/off
- Even more strange, ROM 0 seemed to be completely erased from block 0 of sram! I found out this, when i switched to RAM mode and try to read first 20-25 bytes of each sram block (which correcponds to game roms), and all roms where intact, EXCEPT the 1st rom, returning all zeros...  ???

Any ideas of what i may be doing wrong or where the problem might be?
Btw, is there any other cpr files that should work on Amstrad cpc to try?




abalore

Quote from: ikonsgr on 21:16, 23 October 21
Any ideas of what i may be doing wrong or where the problem might be?
Btw, is there any other cpr files that should work on Amstrad cpc to try?
The Alcon lower ROM is very small, just a bunch of bytes that must be similar to this:

F3 21 0F 00 11 00 40 01 0D 00 ED B0 C3 00 40 01 84 7F ED 49 01 84 DF ED 49 C3 30 C0

If you have that in your SRAM block 0 and that block is mapped to lower, the only thing that can be failing is to translate the range &80-&9F to &00-1F
Alcon doesn't need any other upper ROM mapping. Once the Alcon lower ROM takes control, none of the normal upper ROMs are needed (BASIC, AMSDOS) since the whole game works by accessing the hardware directly. You could run the game in a CPC even with the ROM chips removed from the motherboard.
Just curious, how are you converting the CPR to BIN before dumping it into the SRAM? I recommend you the CPRTools utility, which is very well proven.

abalore

There are other CPRs that run on the CPC, like Rick Dangerous, but maybe you'll need to do the full upper ROM mapping of the Plus:
Lower                            -> slot 0
ROM 0 to 127 (except 7) -> slot 1
ROM 7                           -> slot 3
ROM &80 to &9F             -> slots 0 - 31

ikonsgr

Quote from: abalore on 22:43, 23 October 21
The Alcon lower ROM is very small, just a bunch of bytes that must be similar to this:

F3 21 0F 00 11 00 40 01 0D 00 ED B0 C3 00 40 01 84 7F ED 49 01 84 DF ED 49 C3 30 C0

If you have that in your SRAM block 0 and that block is mapped to lower, the only thing that can be failing is to translate the range &80-&9F to &00-1F
Alcon doesn't need any other upper ROM mapping. Once the Alcon lower ROM takes control, none of the normal upper ROMs are needed (BASIC, AMSDOS) since the whole game works by accessing the hardware directly. You could run the game in a CPC even with the ROM chips removed from the motherboard.
Just curious, how are you converting the CPR to BIN before dumping it into the SRAM? I recommend you the CPRTools utility, which is very well proven.
Yes,i confirm that this is exactly the few bytes of the 1st ROM 0 copied to first bytes of sram.
I have developed my own custom code in order to fetch each rom to sram blocks from a cpr file loaded in a usb stick. Then i run a small basic program which fetches the first ~20 bytes of each sram block (where each rom is mapped to) and compare it with the original bytes of the cpr file. So, i'm pretty sure that all roms are initally transferred correctly to sram.
The very curious thing is that, after i try to run game (and crashes... :( ), when i reset bak to ram mode, and check sram blocks, the 1st block where rom 0 is mapped, is filled with zeros (all other roms are stay intact)!  This is something that it should be impossible to happen, as sram in "rom board" mode, acts exclusively as a virtual rom, responding ONLY to Amstrad's "rom enable" (which are always READing bytes) signals! Unless writing to a RAM address ,where an active rom is also mapped, enables "rom enable" signal, along with "wr" signal from cpu, thus, sram (instead of internal ram) is activated and written!  ???
And as i note before,i have confirm that rom board emulation works ok, as i managed to load FW 3.15 as lower ROM 0 along with french Basic as upper rom 0 (where it's actually loaded to sram block 1 and then use an upper ROM 0->SRAM block 1 mapping), parados and a couple of other rom games in various other rom positions, and everything worked fine! By reset/switch to rom board mode, FW 3.15 with fbasic is loaded ok, and i can execute parados by giving |DRIVE and the rom games with a couple of other rsx commands too!
So i really can't understand, why it's not working with alcon's cpr file....

ikonsgr

 Ok, i've decided to check signals with a logic analyzer and found out that this method of "on the fly" pausing reading of byte from rom (to determine if it's upper or lower rom, and set the 5 highest Address bits of sram accordingly) issues a delay, practically doubling the actual respond  of rom ( from 1us/byte read to ~2us/byte read). Although this doesn't seem to affect proper function of individual roms (appart maybe, from a bit slower reaspond), i guess this might affect alcon2020 from loading properly, not to mention play speed problems (as i guess it must use constant rom reads all the time )
So, i've decided to redesign the circuit, using a larger 40pin PIC microcontroller 18F46Q10 (as the smaller 28pin 18F26Q10 lacks of the required extra pins to accomodate all signals needed) and most important, implement a way of "on the fly" switching between upper/lower rom (when both roms are enabled)  thus, reading bytes from rom, should be done properly without any delays.
I've already order a few prototype boards for this, let's hope this will solve any problems...  ::)

Powered by SMFPacks Menu Editor Mod