General Category > Programming

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

<< < (5/5)

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 23: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?

--- End quote ---
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 00:43, 24 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.

--- End quote ---
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...  ::)

Navigation

[0] Message Index

[*] Previous page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod