MESS: Custom RPKs

[RobertLM78]

Hi all! Since making custom carts has been discussed, I thought I'd create a thread for the purposes of helping people make their own RPKs for use with MESS.

 

I downloaded Gazoo's .bin of a 1 meg cart, and have been trying to make an .rpk out of it. I've assumed (perhaps incorrectly) that the .bin is a ROM. I've got the checksum from sha1, and I think I've set the size right (0x100000), but it isn't working. No doubt, I'm doing something wrong here... I've attached a zip of what I've put together so far.

 

1MegGamecart.zip

[Gazoo]

Hi all! Since making custom carts has been discussed, I thought I'd create a thread for the purposes of helping people make their own RPKs for use with MESS.

 

I downloaded Gazoo's .bin of a 1 meg cart, and have been trying to make an .rpk out of it. I've assumed (perhaps incorrectly) that the .bin is a ROM. I've got the checksum from sha1, and I think I've set the size right (0x100000), but it isn't working. No doubt, I'm doing something wrong here... I've attached a zip of what I've put together so far.

 

 

I'm pretty sure MESS doesn't support the 512k bank switching. The best you'll be able to do is to use Classic99 with the Backwards (or inverted) versions of the individual 512k files.

 

Gazoo

[RobertLM78]

Well, that's too bad . But, I still think it would be good to discuss custom RPKs in general. So is 512k the max that MESS can handle? I'm pretty sure I have another .bin image I'd like to make an RPK out of, so it would be good to know how to put one together still .

[+mizapf]

Hmm ... the biggest cartridge supported with 379i banking was the 128 K version. I did not notice we went up to 1 meg in the meantime. The 128 K version allowed for setting the bank with the addresses 6000 - 601E (even), i.e. 16 banks with 8 K each.

 

Are there real 1 M cartridges, or do we talk about emulation artifacts?

Edited May 31, 2014 by mizapf

[RobertLM78]

Hmm ... the biggest cartridge supported with 379i banking was the 128 K version. I did not notice we went up to 1 meg in the meantime. The 128 K version allowed for setting the bank with the addresses 6000 - 601E (even), i.e. 16 banks with 8 K each.

So 128k (16*8k) is the max size of a cart?

Are there real 1 M cartridges, or do we talk about emulation artifacts?

If I understand things correctly, I suppose they would be. (I don't have a the equipment needed to make real carts, anyway, so that's a moot point ).

[Gazoo]

Hmm ... the biggest cartridge supported with 379i banking was the 128 K version. I did not notice we went up to 1 meg in the meantime. The 128 K version allowed for setting the bank with the addresses 6000 - 601E (even), i.e. 16 banks with 8 K each.

 

Are there real 1 M cartridges, or do we talk about emulation artifacts?

 

The largest single cart is the 512k with 378 banking. A toggle switch can be used with a 1 meg eprom to switch between 2 512k banks.

http://atariage.com/forums/topic/193163-512k-cartridge-status/page-9?do=findComment&comment=3000631

 

Gazoo

[RXB]

Gary Bowser (OPA) and a couple of us sat around in a TI Faire years ago and he discussed the idea of a cart that could be made having 16 pages of 40K groms total of 640K GROM.

 

The head kicker idea was a 16 slot rotary switch that selected one of sixteen 640K GROMs. Thus you would have a 10Meg cart of GROMs in total.

 

Add in a 16K ROM bank for each 40K GROM page and you get 256K ROM per slot, and 16 slots of those totals 4Meg of ROM/RAM

Of course if RAM you need a battery to back it up.

 

That cart could possibly hold most of the carts made for the TI. Really that would be like 400 carts as some are only 16K GROM and thus 2 could be in one page no problem.

[RobertLM78]

I see. And they're not just an 'emulation artifacts' either - I'd forgotten about the picture there in the thread . (I've honestly not been keeping up with that thread - but I should read it all ASAP).

[+mizapf]

You know, according to MESS policy, if there's such a cartridge, and MESS does not support it, I'll have to fix that (some day).

[+Ksarul]

Rich, there is a secondary problem associated with your monster of a cartridge. Though you can theoretically build something that will do that, you will be massively overloading the cartridge port to drive the chips in it. It would probably take out your machine in a few minutes of operation. Once you get to driving more than about 20 chips, you hit the cartridge port's maximum allowed current draw. Now, if it had its own power supply and was buffered from the TI bus, you might just make something like that work--but that is why most large GRAM devices ended up in the PEB. . .it was easier to get the necessary power there.

[RXB]

Well this concept was using the idea of a minimum number of todays modern chips.

Not using anything from back then as you would need another P-Box to power that thing with original TI chips.

 

Low power chips that are massively to large would have to be used. Like say a 1 Gig chip would waste most of the space but be fast and require very little power.

[+Ksarul]

Large chips would also require SMT, 5V to 3V conversion for the power and a buffer to get the levels back up to 5V TTL levels on the outputs (and inputs)--and you'd lose most of the extra speed staying in sync with the TI. It might work, but it would be a royal pain to design. . .

[Gazoo]

Well this concept was using the idea of a minimum number of todays modern chips.

Not using anything from back then as you would need another P-Box to power that thing with original TI chips.

 

Low power chips that are massively to large would have to be used. Like say a 1 Gig chip would waste most of the space but be fast and require very little power.

 

Large chips would also require SMT, 5V to 3V conversion for the power and a buffer to get the levels back up to 5V TTL levels on the outputs (and inputs)--and you'd lose most of the extra speed staying in sync with the TI. It might work, but it would be a royal pain to design. . .

 

The idea would be way overkill, anyway. Just make another run of HSGPL cards. It's got plenty of room to fit all the stuff you use everyday, I don't even have anything to put in the last few banks. And with the 'HSGPL MENU' program, you can load and run ANY cart in the GRAM/RAM space at the press of a key. What more does one need?

 

Gazoo

[RXB]

How hard is it to make GPL programs with the Ryte Data GPL Assembler and load them with the GPL*LOADER into the HSGPL card?

 

From my understanding you can not do this?

 

Or can you GPOKE values into any module? (A GRAMKRACK/GRAMULATER allows this)

[jacquesg]

Rich,

 

IIRC I downloaded most, if not all, of the GPL object files from your GPLHOW2 series and placed them in banks on my HSGPL card. Does the Ryte Data approach not use the Weiand GPL assembler program before having to use the RD Linker to add the 12 (or is it 13) byte header file. Over the last few years I have spent a couple of 4 or 5 months stints in the hospital and I have become a little rusty in my GPL procedures which date back before my hospital visits. I am slowly getting back into GPL. The GPL*LOADER program will definitely load a Weiand GPL object file into a HSGPL bank.

 

I do not want to get into a long discussion comparing the HSGPL card to either of the GRAMKRACKER or GRAMULATOR cards. I have never seen either of these other 2 cards. I know that RXB uses GPOKE in a few of its statements but these do not work with my HSGPL card. Everything else seems to work.

 

Regards,

 

Jacques

[RXB]

The Ryte Data Linker is for making GPL to run from Assembly EA5 prompts.

It does not use GPL in GRAM but GPL in VDP. It is running GPL in a kind of emulator.

 

If a RXB CALL GPOKE does not work then the GPL*LOADER will not work correctly as they both put values into GRAM.

If the HSGPL card is GROM then of course neither would not work as designed.

Unless there is a write protect switch that allows this to take place so you can put it in GRAM then turn the write protect switch back on like a GRAMKRACKER.

 

I need to pour over the HSGPL card to see how it works.

Thanks for the help.

 

Rich

[+acadiel]

Hmm ... the biggest cartridge supported with 379i banking was the 128 K version. I did not notice we went up to 1 meg in the meantime. The 128 K version allowed for setting the bank with the addresses 6000 - 601E (even), i.e. 16 banks with 8 K each.

 

Are there real 1 M cartridges, or do we talk about emulation artifacts?

 

That is correct. The 74LS379 only banked up to four lines, so 16K/32k/64K/128K.

 

The 74LS378 is a newer development that is can bank six data lines. 16K/32K/64K/128K/256K/512K. It has not seen wide release yet and is only starting to gain limited release into the community. If anything, we can probably be safe to extend the MESS TI emulation to support this new bank switch method (which is easy peasy compared to the reverse banking that was the 379 banking.)

 

The 1M cartridge is really a 512K cartridge with a switch on it control whether the TI sees the high 512K of the 1M EPROM or the low 512K of the 1M EPROM. It probably would not make sense to support unless Ksarul or myself build a cartridge with a 74LS377, which can support up to 2M of bank switching. (But also needs 20 pins for the 377 vs 16 for the 378, and a 27C160, which is probably not supported by a lot of programmers, since it's 42 or 44 pins, and most of the less expensive ones top out at 40.)

[+acadiel]

I see. And they're not just an 'emulation artifacts' either - I'd forgotten about the picture there in the thread . (I've honestly not been keeping up with that thread - but I should read it all ASAP).

 

You know you've been watching a certain TV show when you see the word "artifact" and start thinking something like this:

 

 

hehe

[ralphb]

Michael, what's the current status with MESS and homebrew cartridges? According to Ninerpedia, there's only 379i, but no 378.

 

Could we get a generic 378/379 layout where we can specify the number of available banks in the layout.xml? That would make it much simpler to emulate real iron homebrew cartridges, other than the known color boards.

 

Case in point, as a workaround I'm trying to run Pac-Man in 379i mode, so I took PACMAND and PACMANC and duplicated those 16K up to 128K, but the program still crashes as soon as Pac-Man opens his mouth for the first time. Is 379i bigger than 128K now?

 

Configurable banks and invertedness would make it much simpler to replicate the cart one actually has.

 

(Couldn't find the actual MESS thread anymore, but this one seems even better.)

[+mizapf]

Michael, what's the current status with MESS and homebrew cartridges? According to Ninerpedia, there's only 379i, but no 378.

 

Oh ... outdated, as it seems. Currently supported cartridge types:

 

standard

paged

minimem

super

mbx

paged379i

paged378

paged377

pagedcru

gromemu

 

Cartridge type: paged379i

This cartridge consists of one 16 KiB, 32 KiB, 64 KiB, or 128 KiB EEPROM

which is organised in 2, 4, 8, or 16 pages of 8 KiB each. The complete

memory contents must be stored in one dump file.

 

Cartridge type: paged378

This type is intended for high-capacity cartridges of up to 512 KiB

plus GROM space of 120KiB (not supported yet)

 

Cartridge type: paged377

This type is intended for high-capacity cartridges of up to 2 MiB

[ralphb]

Ah, that's useful, thanks for the update. I guess I can live with padding for now.

 

(My MESS still crashes on the duplicated Pac-Man w/378, whereas the original one works. I'm a few MESS versions behind, though, I'll check with the latest one again.)

[+mizapf]

My MESS still crashes on the duplicated Pac-Man w/378

 

means: The emulator crashes, or the emulation?

[ralphb]

Sorry, I meant the emulation. And it's not really crashing either, but Pac-Man is stuck in it's bank-switching loop. For example, it's writing to >646c, but of course the programmers only cared about A1 (modern naming) back then. I don't know how you decode the bank switching, but I duplicating the image should nullify the larger address space when bank switching.

 

I just thought that previous MESS versions might have a different decoding than you described above.

[+mizapf]

Use the source, Luke?

https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99x/gromport.cpp

 

(maybe this can answer your questions)

[ralphb]

Use the source, Luke? (maybe this can answer your questions)

 

Indeed. For the 378:

.

// Bits: 0110 0000 0bbb bbbx
// x = don't care, bbbb = bank
if ((offset & 0xff80)==0x6000)

.

Why do you insist on the upper bits being 0? This is what breaks Pac-Man. Personally, I'd make this

.

// Bits: 011x xxxx xbbb bbbx
// x = don't care, bbbb = bank
if ((offset & 0xe000)==0x6000)

.

Would that break other, modern programs? (I just noticed that's what you do for the 377, so why not for the 378? Is it not true to the original enough? I haven't tried it, but AFAIR the red board also ignores those bits.)