CST Ram Plus eproms - CST QDisc v4 issue

[chriskgnr]

Hello again,
I burned a 27128 eprom with the CSTQD118 scrambled firmware and everything works ok.
About CST Ram plus card, i populate the four empty sockets with varius eproms like 27128 and 27256, programmed with TKII, ICE, MonQL, SpeedScreen, 68K/OS(32KB), Prospero(32KB) and not even one was recognizable at the boot screen.
I also assembled a Trump card v2(with 6 dram chips) and this too works flawless.

[chriskgnr]

I think the eprom sockets decode out as 32K chunks - so you can get 2 16K ROM images per 27256 Eprom.

This will be the next try.

[ones' complement]

Do the files in EPROM have the required ROM header ident/banners at the 16K boundaries where needed? It would be easy enough to knock up simple SuperBasic script to PEEK at the appropriate places and show first few bytes (i.e. at each 16K boundary in top 256K of QL's 1Meg map).

[chriskgnr]

Do the files in EPROM have the required ROM header ident/banners at the 16K boundaries where needed? It would be easy enough to knock up simple SuperBasic script to PEEK at the appropriate places and show first few bytes (i.e. at each 16K boundary in top 256K of QL's 1Meg map).

I didn't check about this(i don't know what to look for), but if you guide me i can check the headers in eprom bin files and change them if they need, with a hex editor.

[ones' complement]

OK, the first thing to do would be to look at each of the files you wanted to add to EPROM in a hex editor. If they are true QL ROMable files then the format of the first few bytes is defined:

Code: Select all

$4A,$FB,$00,$01   unique identification word for ROM code
$??,$??           offset to list of names of new SupreBASIC procs/fns
$??,$??           offset to initialisation routine
$??,$??           length of banner string following
$??,...           banner string shown at boot (end with linefeed)

Any files which do have this format can be added to EPROM, but they must start on a 16K boundary to be recognised. It is OK if they are greater than 16K since any code at the next 16K boundary will not (or should not!) contain the unique $4AFB0001 value.

If any of the files don't at least have the first four bytes then it is not ROM code (though it can be made so, utilities are available or you can do it yourself). The offsets and banner may be absent and so the $?? values may be zero.

Some files may not be suitable for ROM since they either try to write to their location (expecting RAM) or self-modify.

[ones' complement]

AFAIK the 68K/OS(32KB) file is a complete operating system replacement so I don't expect it to be recognised by QDOS/Minerva. Though it will be interesting to see if t0nyt's 68K/OS PCB can be realised as a schematic

[chriskgnr]

OK, the first thing to do would be to look at each of the files you wanted to add to EPROM in a hex editor. If they are true QL ROMable files then the format of the first few bytes is defined:

Code: Select all

$4A,$FB,$00,$01   unique identification word for ROM code
$??,$??           offset to list of names of new SupreBASIC procs/fns
$??,$??           offset to initialisation routine
$??,$??           length of banner string following
$??,...           banner string shown at boot (end with linefeed)

Any files which do have this format can be added to EPROM, but they must start on a 16K boundary to be recognised. It is OK if they are greater than 16K since any code at the next 16K boundary will not (or should not!) contain the unique $4AFB0001 value.

If any of the files don't at least have the first four bytes then it is not ROM code (though it can be made so, utilities are available or you can do it yourself). The offsets and banner may be absent and so the $?? values may be zero.

Some files may not be suitable for ROM since they either try to write to their location (expecting RAM) or self-modify.

I used HxD hex editor to read ICE 1.21 and TK2 2.23 rom files and the four bytes sequence $4A,$FB,$00,$01 is at the start, followed by six bytes and then it comes the banner text shown at boot. Almost identical are the byte sequence for rom slot bin files that don't show the banner text at boot. If this byte sequence is used only for 16KB bin files for the Rom slot what about the 32KB rom files?

[Pr0f]

a 32K ROM image would usually just have 2 16K images in it - one at the start and one on the 16K boundary

[ones' complement]

If this byte sequence is used only for 16KB bin files for the Rom slot what about the 32KB rom files?

The byte sequence $4AFB0001 can be used for any size ROM files (within available space), not just 16K. AFAIK that sequence was chosen because it was least likely to occur in normal binary files. Any 16K boundary (within $C0000-$FFFFF) that has not got that sequence is ignored (it could be additional code from previous 16K boundary). I'm not aware of any utility ROMs greater than 16K (i.e. ones that are usually added to ROMport). If the 32K files don't have $4AFB0001 header then they are not suitable (e.g. 68K/OS).

I still have an old Harman EPROM card (3x 64K EPROM), before Trump and Gold card I used to have 192K of various things on it (PE, etc). As mentioned there are several EPROM manager utilities available. AFAIK as long as the code is well behaved it can be put on EPROM somehow. IIRC I think I just had one 192K file across the three 64K EPROMs with everything on it with just one $4AFB0001 header.

[tofro]

The QL memory map reserves (interestingly, much like the IBM PC) address space above $C0000 for I/O cards with 16k per slot. How this address space is used by the card (registers, ROM,...) is up to the card. QDOS will, on startup, scan the ROM port address ($C000) and the base addresses of each of these slot's for ROM header signatures. If it finds one, it will (if you're not using a buggy QDOS version) link in the S*BASIC functions in the ROM and call the initialization routine. The Technical Guide somewhat implies that no single card (except RAM cards) can use more than 16k of address space (So, a 32kB ROM on an expansion board would somewhat conflict with that implication, but probably still work. I doubt, however, that such a card was ever made). As most hardware add-on-cards would need at least some I/O registers with in their 16k address space, it's likely a full 16k ROM was never implemented on expansion cards.

There is reserved space for a pure ROM add-on card at the top 128k of the address space.

Whever is interested in how this was originally intended to work, should consult chapter 11 of the QL Technical Guide.

The Miracle TrumpCard, of course ignored all this, didn't use a dedicated I/O space (but rather overlaid its registers in the motherboard I/O space) and filled everything else with RAM