Mega Games Cartridge for the Electron MGC

[Elminster]

As I mentioned, I'm using BeebEm3 for the Menu development - but can't load the 4mb ROM

Beebem 3 on the Mac? Just crashes when I have tred to use it, although never got around to looking at why, assumed it didnt work on latest versions of MacOS. I now just run Beebem 4 in VMware on Windoze.

[daveejhitchins]

Beebem 3 on the Mac? Just crashes when I have tred to use it, although never got around to looking at why, assumed it didnt work on latest versions of MacOS. I now just run Beebem 4 in VMware on Windoze.

I've had it crash when I've 'nipped' out to Excel and back again. So I just save regularly now

Dave H

[richardtoohey]

By ROM table, you mean &F4 and &FE30 or something else (*ROMFS)?

The ROM table is the table at &2A1-&2B0 (&2A0-&2AF on the Electron) that is a table of the ROM type bytes of each ROM so the operating system knows if there's a ROM in that slot. It is initialised at Break (Ctrl-Break on the Master). Some versions of *SRLOAD have a I parameter that "inserts" the ROM into the ROM table after loading so that it can be seen.

Thanks.

Not sure if it is needed any more (depending on the way forward), but I decided to go and look at the right way of reading the address of the ROM info table, and it's OSBYTE &AA. Got a bit confused about why my program works after Break, but then goes wrong?

Code: Select all

10 P%=&900
20 [
30 LDA#&AA
40 JSR &FFF4
50 STX &70
60 STY &71
70 RTS
80 ]
90 CALL &900
100 PRINT ?&70,?&71

First run on an Electron, I get "160 2" output - correct &2A0. Run same code on Master, output "161 2" - correct &2A1.

Re-run on Electron - "0 2", or Master "0 163".

Press Break on either, OLD, RUN, correct values again. What's that all about?

(Running on elkulator and beebem, but don't think to do with emulators. EDIT: tried on real Electron and same behaviour.)

[richardtoohey]

Prommer v1.0 -Hugh Haskell -The Micro User 1987 (*FILE instant load, not RFS)

Instant load sounds interesting, so having a look at this now ...

EDIT: June 1987, pages (thanks, 8bs.com!) extracted and attached. (The code was in an earlier upload from Col.)

EDIT2: There's also David B's comments on making a ROM version of Jungle Journey:

http://www.retrosoftware.co.uk/wiki/ind ... 1-10-16.29

Jungle Journey, code plus data, is larger than 16K in size, making it difficult to consider making a cartridge with a single ROM. Out of necessity, two ROM images need to be created and used: the first contains sprite data and "loader" code that copies the data into memory; the second contains the game code and is run from ROM. To "load" the second ROM from the first, I used what I consider to be a dirty trick: I copy a small piece of code to start the second ROM image from ROM into RAM, then execute it. I'm sure there must be a nicer way to call one ROM from another.

Sounds like to do this, though, you'd need to write custom code/shuffle files around to work from ROM.

The advantage of ROMFS is that you don't - you can copy the files from the existing game as is, no real faffing around, other than making sure they split cleanly into 2 16K chunks. I think.

So for MGC, you could just choose some games, whack them onto ROMFS OR you'd have to work on a custom loader and split the files carefully across the 2 banks (if two are required.) Quicker loading, but definitely more work to achieve, because you'd have to do it for each and every game.

Am I right or barking up the wrong tree or just barking?

[davidb]

Another way to get instant loading for some games might be to take a memory snapshot when the game has loaded, perhaps in an emulator, and create ROMs from that. Maybe the Slogger Click cartridge can do part of that process.

[paulb]

Another way to get instant loading for some games might be to take a memory snapshot when the game has loaded, perhaps in an emulator, and create ROMs from that. Maybe the Slogger Click cartridge can do part of that process.

Extra credit is also available for providing a mechanism to "persist" high scores in a special region of the MGC for certain supported games. If Richard wants a challenge, that is.

[richardtoohey]

@paulb ... ... Richard finds it a challenge working out which end of a spoon to use! And don't talk to me about high scores. Or maybe that was the joke?

Back to the menu, and making it a bit faster ... if the menu is ROMFS, split over two banks, couldn't you have some sort of scheme whereby the catalogue is just a set of files? I've been looking at my Starship Command ROM (Col's listed the contents on this thread) and reading my Bruce Smith Advanced Sideways RAM User Guide and I'm hopefully catching up with the rest of you now!

So first bank, BASIC menu, and some catalogue files.

Second bank, more catalogue files.

Thinking of catalogue files as being something like ...

Electron EGAMES EUTILS ELANG
Master MGAMES MUTILS MLANG
Both BGAMES BUTILS BLANG

Then when the menu runs, and you chose machine, app type, it *LOADs the appropriate catalogue files. Something like that.

I went down this line of thinking because I was wondering if *LOAD from ROMFS would be quicker than OSRDRM (one byte-at-a-time)

But then maybe the current plan is fine ... if you are running from bank 0 you know the catalogue must be in bank 1 (or vice versa), or if you are in 2 the catalogue is in 3 (or vice versa). So you can (but not from BASIC) switch ROMs to the other bank of the pair, LDA from &8000 the catalogue, and Bob is your uncle!

Am I on the right track with this last set of thinking, Dave? A BASIC program with a bit of m/c to slurp stuff off the second bank - would be a lot quicker than OSRDRM.

[sweh]

Code: Select all

10 P%=&900
20 [
30 LDA#&AA
40 JSR &FFF4

First run on an Electron, I get "160 2" output - correct &2A0. Run same code on Master, output "161 2" - correct &2A1.

You need line "35 LDX#0:LDY#255" because osbyte &AA sets "new_value=(old_value AND Y) EOR X

[daveejhitchins]

Am I on the right track with this last set of thinking, Dave? A BASIC program with a bit of m/c to slurp stuff off the second bank - would be a lot quicker than OSRDRM.

Sorry Richard, I've been trying to 'finish-off' my work before Tenerife on Wednesday, for a week

I 'm thinking that sticking to the BASIC Menu would be good, easier to maintain(?). But have a m/c section to read the Index File, in place or the OSRDRM. The Index File has a section that can point to a 'loader'. It would be handy if the loader were common. I think this can be achieved by having a 'small' section of 'information' at the beginning of the file to be loaded. It could be a separate file that contains 'how' the game is to be loaded. Doing it this way will save having to replicate the loader for each game. There is even time to change the Index File Format to include further information, if it's needed, there's still room left Regarding space for the loader . . . I think there should be room in the Menu 16K bank - The Menu compresses quite well!

Dave H

[richardtoohey]

Not sure what I can do to help The requirements are a bit fluid.

Do want to help, though.

Menu in BASIC, fine, nice and simple. Do you want/need a machine code section to slurp the catalogue from ROM, or is OSRDRM looking fast enough? In which case what you've already got is fine, job done.

Loader - guess you are meaning something that takes some parameters and takes care of things (e.g. PAGE at &xxxx, CHAIN "file" or *RUN file or whatever.) I still don't see how that works without ROMFS for multi-file titles (e.g. BASIC loader with envelopes, VDU 23s, loading a title picture, loading GAMEPT1, *RUN GAMEPT2) without a bit of work.

Anyway, you are busy so I'll wait. Plenty of other projects to get on with.

[daveejhitchins]

Do want to help, though.

Is the Pope Catholic?

Menu in BASIC, fine, nice and simple. Do you want/need a machine code section to slurp the catalogue from ROM, or is OSRDRM looking fast enough? In which case what you've already got is fine, job done.

The main BASIC Menu is fast enough. And, compressed, small enough. OSRDRM way too slow! So, this is ideal for conversion to m/c.

A replacement for OSRDRM. A m/c routine called with: SLOT, NXTADD + offset (for the 'start' position) + a byte to say if it's [a] single byte fetch (nothing follows) Multi byte fetch type 'A' followed by number of characters. Or 'B' this would look for a terminating byte e.g. &FF.

Loader - guess you are meaning something that takes some parameters and takes care of things (e.g. PAGE at &xxxx, CHAIN "file" or *RUN file or whatever.) I still don't see how that works without ROMFS for multi-file titles (e.g. BASIC loader with envelopes, VDU 23s, loading a title picture, loading GAMEPT1, *RUN GAMEPT2) without a bit of work.

It may be possible to load-the-game as authentically as possible, and I'm sure there will be votes for that method. However, as a start, if we can load the game instructions and the game itself, in double quick time, I think we'd be doing OK(?)

I'll continue developing the BASIC Menu structure (still needs work) adding the small m/c section, mentioned above, next, as I think getting it working in BASIC first is probably the easiest way forward. The OSRDRM replacement can be added as and when it's been developed, as can the main game Loader. Getting something out in the wild, that works, will be a good start. Updates can always be 'issued' at a later date.

Do I need help . . . I'd like to think I don't . . . But reality says I do. So the OSRDRM routine is the first candidate, please . . . But only if you have the time?

Dave H

[richardtoohey]

A replacement for OSRDRM. A m/c routine called with: SLOT, NXTADD + offset (for the 'start' position) + a byte to say if it's [a] single byte fetch (nothing follows) Multi byte fetch type 'A' followed by number of characters. Or 'B' this would look for a terminating byte e.g. &FF.

Do I need help . . . I'd like to think I don't . . . But reality says I do. So the OSRDRM routine is the first candidate, please . . . But only if you have the time?

I want a real 6502 project to get back into the swing of things, so this is ideal for me. You'll get there without me if I do fall by the wayside (or if I'm just taking too long), but I'd like to give this a go. So I will.

So we need a routine that takes slot/bank# (byte), address (16-bit word), and size (byte). Size could be 00 for read until terminator (FF), or 1 to FF for multibyte reads.

A%=00 - read until terminator (FF), otherwise # bytes to read
X%=low of param block
Y%=high of param block

param block
byte 00 slot/bank - 0 to 15
bytes 01 & 02 source address (in ROM), low, hi. So expected to be &8000 or higher.
bytes 03 & 04 destination address in RAM, low, hi. So expected to be below &8000

Routine reads its params, switches in the correct ROM, reads # bytes from ROM (source) into RAM (destination), and returns #bytes read.

I'll give that a go. Sure this has been done before, so there is bound to be code around already, but where's the fun in that?

[1024MAK]

As it is likely to be kilobytes of data that is being copied, would it make more sense to have a 16 bit word for the size/length to be copied?

Mark

[Elminster]

I want a real 6502 project to get back into the swing of things, so this is ideal for me. You'll get there without me if I do fall by the wayside (or if I'm just taking too long), but I'd like to give this a go. So I will.

I with you on that. Following the thread with interest as a) learning assembly, relearning BBC Basic and b) now have a (plus1less) Electron. Reading 2 books on Assembly and the Exmon manual at the same time (in a time division way not in parallel).

Now I think I also need to add in those Bruce Smith books about ROMs and being sideways as well.

So keep putting all the details in here. I nearly understand some of it. You never know at some point I might actually be able to contribute something.

[richardtoohey]

As it is likely to be kilobytes of data that is being copied, would it make more sense to have a 16 bit word for the size/length to be copied?

Mark

I did think about that but (a) makes it slightly more complicated and (b) think Dave wants to read index entries (~40 bytes) or parts thereof at a time.

So maybe (for me) a version 2 thing. I'm aiming to walk before I run ...

BUT maybe I make it 16-bit now in the param block, and just process the low byte. So room to expand the code without needing to change the caller code or param block.

But then I have to shuffle things around, and can't make the return (# bytes) fit into 8-bits anymore ...

EDIT - and if you are doing the read until &FF, and whacking into RAM, if there is no &FF, then you'll potentially trample a lot of RAM. So you'd probably need extra code to check that you don't rampage through too much memory.

[richardtoohey]

Following the thread with interest as a) learning assembly, relearning BBC Basic and b) now have a (plus1less) Electron. Reading 2 books on Assembly and the Exmon manual at the same time (in a time division way not in parallel).

I knew a little bit of assembly BITD - but more as a reader than a writer, so I'm expecting lots of suggestions about improving what I eventually come up with. But if I manage to start with something that even works, I'll have impressed myself!

[richardtoohey]

Code: Select all

10 P%=&900
20 [
30 LDA#&AA
40 JSR &FFF4

First run on an Electron, I get "160 2" output - correct &2A0. Run same code on Master, output "161 2" - correct &2A1.

You need line "35 LDX#0:LDY#255" because osbyte &AA sets "new_value=(old_value AND Y) EOR X

Thanks, Stephen. I did see that part but didn't understand it.

Actually, I still don't quite understand it. New value of what? This is a function to read the address of the ROM table. Or does it also change it? Guess it must do ...

Thanks.

[Elminster]

Actually, I still don't quite understand it. New value of what? This is a function to read the address of the ROM table. Or does it also change it? Guess it must do ...

Thanks.

Me neither but I found this http://www.8bs.com/hints/179.txt

The important bit was

If you want to READ the register without altering the contents, then simply
make the appropriate call with X=0 and Y=255, and the current value in the
register will usually be in X on exit.

[richardtoohey]

Here's a stab at a very basic function. It uses zero page to make things a lot easier. It doesn't have the checking for &FF terminator - you just tell it where to start in which ROM, and how many bytes you want. Think there needs to be a SEI/CLI somewhere when selecting ROMs?

But it works. Change BANK% in line 20 to 0 on my Beebem BBC machine & run the code:

Code: Select all

EXMON II 2.01 (C)1987 Beebug

Try BANK%=14

Code: Select all

DFS 0.90

Try BANK%=15

Code: Select all

BASIC (C)1982 Acorn

Boils down to setting BANK%, SIZE% and calling

Code: Select all

B%=FNreadrom(BANK%,SIZE%,&8000,BUF%)

Returns the number of bytes read (well, actually just returns the number of bytes you asked for.) &70-&75 get trashed.

So change that &8000 to the catalogue entry you want to read, call the function, and BUF% will contain the catalogue entry.

You can change the OPT to hide the assembly output.

I'll carry on with this to add the extra bits (scan until &FF terminator.)

Code: Select all

   10 REM READROM
   20 BANK%=0
   30 SIZE%=40
   40 DIM BUF% SIZE%
   50 P%=&900
   60 FOR I%=0 TO 3 STEP 3
   70 [OPT I%
   80 \ SWITCH IN REQUIRED ROM
   90 \ FIRST SAVE CURRENT ROM
  100 LDA &F4
  110 PHA
  120 \ GET REQUIRED ROM
  130 LDA &70
  140 STA &F4
  150 STA &FE30
  160 LDY #0
  170.copy
  180 \ LOAD FROM SOURCE (ROM)
  190 LDA (&72),Y
  200 \ STORE IN DESTINATION (RAM)
  210 STA (&74),Y
  220 INY
  230 CPY &71
  240 BNE copy 
  250 \ RESTORE OLD ROM
  260 PLA
  270 STA &F4
  280 STA &FE30
  290 \ RETURN BYTES READ TO BASIC
  300 LDA &71
  310 RTS
  320 ]
  330 NEXT
  340 PRINT "READING ..."
  350 B%=FNreadrom(BANK%,SIZE%,&8000,BUF%)
  360 PRINT B%
  370 FOR D%=0 TO B%-1
  380 C%=D%?BUF%
  390 IF C%>31 AND C%<127 PRINTCHR$C%; ELSE PRINT
  400 NEXT
  410 END
  420 DEFFNreadrom(slot%,size%,src%,dst%)
  430 ?&70=slot%
  440 ?&71=size%
  450 ?&72=src% MOD 256
  460 ?&73=src% DIV 256
  470 ?&74=dst% MOD 256
  480 ?&75=dst% DIV 256
  490 REM USR RETURNS PXYA
  500 =USR(&900) AND &000000FF

Hey, I just wrote some 6502 assembly!

[daveejhitchins]

As it is likely to be kilobytes of data that is being copied, would it make more sense to have a 16 bit word for the size/length to be copied?

Mark

Err! No, the maximum number of bytes to be copied is fixed by the length of the "Title" which is currently 30+ the terminator. It could, of course be shorter!

Dave H

p.s.
Remember: All the Variables will be defined in the BASIC program e.g. SLOT% NXTADD%. Will that be of any use?
p.p.s. Don't forget you have to cater for the Master too. e.g. ROM Paging Address!

[1024MAK]

As it is likely to be kilobytes of data that is being copied, would it make more sense to have a 16 bit word for the size/length to be copied?

Mark

Err! No, the maximum number of bytes to be copied is fixed by the length of the "Title" which is currently 30+ the terminator. It could, of course be shorter!

Sorry Dave, I was thinking the same routine would be used to copy the program data from ROM into RAM.

Mark

[richardtoohey]

p.p.s. Don't forget you have to cater for the Master too. e.g. ROM Paging Address!

I change BANK% to &A, run on a Master, output is

Code: Select all

ViewSheet B1.0 (C) 1984 Acornso

(it is truncated because I'm only reading the first 40 bytes from the ROM)

This initial code I'm doing is for the menu. So the menu will load from either 0/1 or 2/3. You've got code in the BASIC program to work out which slot/bank the menu is in. So the BASIC menu program can call this routine with the other bank of the pair to read catalogue entries.

So BASIC menu knows it is bank 0, catalogue is bank 1. Menu bank 1, catalogue must be 0.
Or BASIC menu knows it is bank 2, catalogue is bank 3. Menu bank 3, catalogue must be 2.

With the routine as it is now, you can gobble an entire catalogue entry (hopefully) a lot faster than picking individual bytes out using OSRDRM.

I will carry on with the code so that it can read single bytes, or an &FF-terminated string, but was hoping what I've done already will be useful (at least for testing performance in comparison to OSRDRM.)

[daveejhitchins]

Darn, I'm in Tenerife at the moment. From 5 degrees to 30. So I'll be merely keeping up - but the keys on my '5' are tiny so replies are a pain.

Dave H

[richardtoohey]

Darn, I'm in Tenerife at the moment. From 5 degrees to 30.

Life is hard, eh?

Enjoy the good weather and we can pick this up later.

[rcook]

Here's a stab at a very basic function. It uses zero page to make things a lot easier. It doesn't have the checking for &FF terminator - you just tell it where to start in which ROM, and how many bytes you want. Think there needs to be a SEI/CLI somewhere when selecting ROMs?

But it works. Change BANK% in line 20 to 0 on my Beebem BBC machine & run the code:

Code: Select all

EXMON II 2.01 (C)1987 Beebug

Try BANK%=14

Code: Select all

DFS 0.90

Try BANK%=15

Code: Select all

BASIC (C)1982 Acorn

Boils down to setting BANK%, SIZE% and calling

Code: Select all

B%=FNreadrom(BANK%,SIZE%,&8000,BUF%)

Returns the number of bytes read (well, actually just returns the number of bytes you asked for.) &70-&75 get trashed.

So change that &8000 to the catalogue entry you want to read, call the function, and BUF% will contain the catalogue entry.

You can change the OPT to hide the assembly output.

I'll carry on with this to add the extra bits (scan until &FF terminator.)

Code: Select all

   10 REM READROM
   20 BANK%=0
   30 SIZE%=40
   40 DIM BUF% SIZE%
   50 P%=&900
   60 FOR I%=0 TO 3 STEP 3
   70 [OPT I%
   80 \ SWITCH IN REQUIRED ROM
   90 \ FIRST SAVE CURRENT ROM
  100 LDA &F4
  110 PHA
  120 \ GET REQUIRED ROM
  130 LDA &70
  140 STA &F4
  150 STA &FE30
  160 LDY #0
  170.copy
  180 \ LOAD FROM SOURCE (ROM)
  190 LDA (&72),Y
  200 \ STORE IN DESTINATION (RAM)
  210 STA (&74),Y
  220 INY
  230 CPY &71
  240 BNE copy 
  250 \ RESTORE OLD ROM
  260 PLA
  270 STA &F4
  280 STA &FE30
  290 \ RETURN BYTES READ TO BASIC
  300 LDA &71
  310 RTS
  320 ]
  330 NEXT
  340 PRINT "READING ..."
  350 B%=FNreadrom(BANK%,SIZE%,&8000,BUF%)
  360 PRINT B%
  370 FOR D%=0 TO B%-1
  380 C%=D%?BUF%
  390 IF C%>31 AND C%<127 PRINTCHR$C%; ELSE PRINT
  400 NEXT
  410 END
  420 DEFFNreadrom(slot%,size%,src%,dst%)
  430 ?&70=slot%
  440 ?&71=size%
  450 ?&72=src% MOD 256
  460 ?&73=src% DIV 256
  470 ?&74=dst% MOD 256
  480 ?&75=dst% DIV 256
  490 REM USR RETURNS PXYA
  500 =USR(&900) AND &000000FF

Hey, I just wrote some 6502 assembly!

And &FE30 becomes &FE05 on an Electron...

[Elminster]

And &FE30 becomes &FE05 on an Electron...

Which would imply that only the copy of the ROM Select Registry in &F4 is need to read data for a ROM. As you say the Sheila address on the Electron is different.

There is a 28 line piece of code in 'The BBC Micro ROM Book' for reading bytes from a ROM and that appears to only use &F4. (I just happened to be reading the book, when I read this post).

[1024MAK]

I think that only works if the OS interrupt routine is still active and can switch ROMs before the code actually accesses the ROM. Otherwise how would the hardware at address FE30 / FE05 know what is at RAM address 00F4....

Edit, unless you only want to read the ROM currently selected by the OS.

Mark

[MartinB]

...reading bytes from a ROM and that appears to only use &F4.

Unlikely - $F4 is just a software copy of the relevant hardware register and is necessary because the latter is write-only. It wouldn't be possible to track which rom was selected at any given time without a soft copy.

If you disable interrupts, you can in your own assembler code select and read any rom or sequence of roms you like using only $FE30 (or Elk $FE05) and ignore $F4 updates as long as you finally set $F4 to match the last selected rom before re-enabling interrupts.

[1024MAK]

...reading bytes from a ROM and that appears to only use &F4.

Unlikely - $F4 is just a software copy of the relevant hardware register and is necessary because the latter is read-only. It wouldn't be possible to track which rom was selected at any given time without a soft copy.

Err, Martin means the hardware register at address FE30 / FE05 is write only. A read of this address will not return the last written value, as there is no hardware to provide the CPU with the value stored in the latch. It is the output from the latch that provides the additional address decoding to select the requested ROM chip.

Mark

[MartinB]

Just a typo Mark.