MESS: Custom RPKs

[+mizapf]

I just downloaded the data sheets of the 377 and 378; the 377 has 8 flipflops, and the 378 has 6 flipflops. You're right to say that I should just ignore the excess bits to the left. I suppose the cartridge does not enforce those bits being set to 0. However, the 378 will still only consider 6 bits for switching. Guess it's time to apply a patch.

[+mizapf]

Ouch... just noticed: These cartridge types should be broken in the current release. The reason is that I clipped the address bus to the 13 lines that show up in the real cartridge port, and so offset may only have a value from 0000 to 1fff.

 

Definitely time for a patch.

[+mizapf]

I just noticed one thing while fixing the paged37x cartridges in MESS. The Spaceballs video clip was offered for a 378 cartridge, but the video stopped and repeated very soon on MESS. I noticed that it runs to the expected end when I set the type to paged377.

 

I'd expect that for this video you really need the 74LS377 because of the size. If I understood correctly you can only have 64 pages in a 378 cartridge, i.e. there is a definitive end at 512 KiB. However, js99 runs that cartridge with type 378. That should not be correct, compared to real iron.

 

BTW, it's last Wednesday of April, so there is a new MAME release (0.173).

[Tursi]

The names are more conventions than enforcements of hardware -- 379 type is "inverted" and 378 type is "non-inverted", the actual hardware on the cartridge can vary without affecting that. Nobody else uses "377" as a type, which is probably where the confusion is coming from.

[+mizapf]

Then it would have been better to call the types "paged379i" and "paged37x". Because now js99 tolerates 378-typed RPK cartridges with more than 512K, while MESS rejects them. I don't feel good calling it paged378 when there is no 378 but a 377 on board.

 

@rasmus?

[ralphb]

Why even obsess with the particular IC used for banking? I can force a 377 instead of a 378 into a red board, and it'll work. I can build boards that use two 377s, or a 273 for bank switching ...

 

If you'd just have "pagedn" and "pagedi" (and optionally another attribute to override the bank count derived from the file size) you could cover any board.

[+Ksarul]

True--and the board Marc and I recently worked out uses the 74LS174 as the switch in a 512K cartridge, but it also uses the non-inverted format. The non-inverted format for physical cartridges is currently maxed out at 2048K from a physical hardware standpoint, but larger is possible if it moves to 3.3V surface-mount parts. That said, the non-inverted format uses a lot of different chips to perform the latching, but they are all work-alike solutions with different maximum capacities. The maximum currently in physical form is 2048K, but Tursi has created images up to 32MB within Classic99 to support potential future growth of the physical format.

 

At the moment, no one has built an inverted mode board that is greater than 128K, but there are plenty of design tricks that could conceivably extend that format to the larger sizes as well (using a GAL as the latch generator, for example).

[+mizapf]

Why even obsess with the particular IC used for banking?

 

Maybe because I want to emulate the cartridge and not just simulate it?

 

However, as we have so many variants, it could be justified to relax that rule at this point, or we'd get a zoo of types.

 

 

If you'd just have "pagedn" and "pagedi" (and optionally another attribute to override the bank count derived from the file size) you could cover any board.

 

I'd like to have clear distinction between the traditional (Extended Basic) paging, and the currently used one. So "paged" should remain reserved for Extended Basic-style, and the new one should get a recognizable name. What about "multipage" and "multipageinv"?

 

Renaming the type would require updating the RPKs, but this should not be too hard I guess.

[Tursi]

Maybe because I want to emulate the cartridge and not just simulate it?

All you need to know to do that is whether it's inverted (the 379 IC supports both!) and how many bits of address are captured. The internal behavior of the latches is common enough that I don't expect you'll be tracking down lot numbers to see how they initialize.

 

I'd like to have clear distinction between the traditional (Extended Basic) paging, and the currently used one.

You could, but how do you define the difference? XB has a one bit latch, and due to the way the ROMs have been distributed, I honestly don't even know if it's inverted or not, I couldn't find a schematic.

[+mizapf]

You could, but how do you define the difference? XB has a one bit latch, and due to the way the ROMs have been distributed, I honestly don't even know if it's inverted or not, I couldn't find a schematic.

 

Yes, this is the special point of the Extended Basic cartridge: the 1-bit latch. The current cartridges can latch more bits, which makes the difference.

 

It's not a functional thing (never was in MAME / MESS :-) ), it's a matter of how it was done. Sure, not everything in the code already fully complies with this idea, but I'm constantly working towards it. In that sense, "paged" is the name of the cartridge type that was used for Extended Basic and some more cartridges with a 1-bit latch. I don't have schematics of all those either, but if it once turns out that the 1-bit latch was implemented differently this could be a good reason to split the "paged" type into several types with identical behavior but different realization.

 

Suggesting that we should abstract from the actual circuitry means simply to cover all variants of the current homebrew cartridges. If that is OK for those using these kinds of RPK, I'll replace the multi-paged cartridge types by the two types "multipage" and "multipageinv". But this would entail a patch in js99er as well.

[Asmusr]

JS99'er treats any type but "paged379i" as non-inverted. If there was a new type called "multipageinv" I would add that as well, but I would continue to support the old types.

[+mizapf]

OK, I'd just like to avoid that we eventually have RPKs that run on one emulator only. Maybe we can phase out the old names after some time.

[Tursi]

OK, I'd just like to avoid that we eventually have RPKs that run on one emulator only.

If you keep changing definitions you're going to end up with "this RPK only works on this emulator and MESS version X, and this RPK only works on that emulator and MESS version Y", and the user will have no way to tell from outside the file. It's not very user friendly. I know that's not a goal, but IMO it should at least be a consideration. Consider extending your datatypes instead of changing them! I have a suggestion below.

 

Yes, this is the special point of the Extended Basic cartridge: the 1-bit latch.

 

It's not a functional thing (never was in MAME / MESS :-) ), it's a matter of how it was done.

And this is my point. I can build an Extended BASIC cartridge using any of the above mentioned banking chips -- the console doesn't care. So shouldn't we look at the schematic and see how it was /actually/ done?

 

The 1-bit latch isn't actually what make XB special (and I found the details... Bunyard's manual notes that it's a 74LS00 NAND and a 74LS74 flip-flop, which makes sense). It's the fact that it's a 12k ROM with only 4k banked, instead of banking the full 8k space like pretty much everything else (ie: AtariSoft). For the sake of preservation of hardware details, that's the part that is important to note (and I was under the impression that you already do, although I don't know what you expect for input ROM files).

 

For that matter, AtariSoft carts didn't use an external banking device at all, they did ROM and banking inside a single custom chip (or at least Defender did, that's the only one I've taken apart). So AtariSoft needs a different file type than the 379-based 16k carts...? Are they inverted or not? We actually don't know and can't easily find out -- you have no choice here but to guess.

 

How about this: why not a cartridge flag that defines whether a cartridge file is based on specific, confirmed schematic behavior, where you define the actual banking circuit in use, or is a general definition used as a placeholder for ROM data whose circuit is unknown or generally defined (such as many modern carts)? Then you can have a specific definition for each of the older carts and a flexible open definition for the modern homebrews.

 

For example, Extended BASIC could have the "paged12k" type (or whatever), and a modern 64k cart could have "bankinv_3bits" (or something similarly well defined, so it can be machine-read). Then you can have both goals -- accurate hardware documentation and flexibility for modern flexible designs explicitly tagged as being non-specific.

[+mizapf]

You're making a good point. I'll better copy that text.

 

Indeed, I inherited the cartridge types from the earlier implementation, and while I was writing my previous message I thought that I should pick up a screwdriver and actually look inside my old cartridges.

[Tursi]

I had a thought on the bus this morning, because this has been percolating in my head for years (how to marry your desire to preserve hardware details with my desire for a flexible cart format)...

 

What if we defined a new type that was definable along the lines of a programmable array device? That is, we can define each of the address pins via a simple formula representing the logic that drives that pin. Like a PAL or GAL of old.

 

You could then simply define each address pin in the definition of the cart, and all the information needed would be right there, regardless of emulator and regardless of whether the cartridge layout existed when the emulator was written. Naturally it would be difficult to cover all cases, but I'm thinking a simple latch definition with ANDs and ORs would cover everything we have right now... and probably much of the future.

 

I'm not sure I can explain it well, and I'm still thinking about how it would be coded to execute efficiently (I'm thinking boiling it down to a set of masks, but I need to take a stab at the code to flesh that thought out). But the definition would start by defining all the pins on the cartridge port (or at least the ones the emulator supports). These are the available inputs. We can then define each output pin - for now just sticking to address lines.

 

The cartridge type would define the mechanism for running the 'script' and latching the address. So, for instance, the 16k board would be something like this (I'm making up the names here, hopefully they are clear). Also, please disregard that I'm using INI format instead of XML, it's easier to type.

 

[HW_Definition]
; cart type latches address bits via ROM write
Type = Banked_ROMWrite

; free-form name for this cartridge (not a type, specific to THIS RPK)
Name = 16k cartridge

; address numbering is an issue... TI insists that A0 is the MSB and everyone else
; says A0 is the LSB. Furthermore, to support larger than 8k EPROMs, we need to add
; more significant bits. For now, then, the output bits are numbered for the EPROM
; (where A0 is least significant), and the input bits from the cartridge port are
; numbered for the TI (where A15 is the least significant)
;
; the cartridge port has A3-A15, so those are available for input, but I propose
; that all lines are available for the math - including data lines and CRU lines
; (noting that CRU lines are not available on later consoles in case the emulation
; runs in that mode, but there ARE carts that use them).
;
; In this example, we have a 16k EPROM, with address lines from A0-A13, and the
; TI port has A3-A15. The left side is the EPROM (A0=lsb) and the right side is TI (A0=msb)
; Since the type is ROMWrite, the latched bits are re-evaluated during a write to the ROM space.
;
; in this first stab at a syntax:
; Any defined pin is latched. Undefined bits are not latched and mapped directly to the cart port,
; mapping LSB to LSB automatically.
; ~  indicates a non-latched pin that is explicitly defined (to override the auto-mapping, if necessary)
; +  indicates an OR operation
; *  indicates an AND operation
; !  indicates an inversion
; L indicates a latch variable (assigned on latch event, can be read otherwise)
; No order of operations - evaluate from left to right
;
; (so the lower 8k is not latched, so we need not define it. We just define the one most significant bit)
; EPROM A13 is most significant bit, TI A14 is second least significant bit. This is an inverted cart.
LA13 = !A14

Using that system, XB would look like this:

 

[HW_Definition]
; cart type latches address bits via ROM write
Type = Banked_ROMWrite

; free-form name for this cartridge (not a type, specific to THIS RPK)
Name = TI Extended BASIC

; latch event - only A13 is latched - TI second least significant address bit (inverted?)
LA13 = !A14

; every access - lower 4k (A0-A12) is fixed, upper 4k is banked. Need to make
; it work inside of a 12k virtual EPROM, though the hardware was an 8k and a 4k
; the hardware was a bit easier because it didnt need to deal with A14 on the 4k ROM,
; but we do.
; So anytime the TI A3 is zero, we are in the 4k space, non-banked. So A3 becomes
; an enable of sorts here. Note how we override A12 here. We dont need to specify A13,
; it will automatically be pulled from LA13 since theres no corresponding TI pin.
A12 = LA13 * A3

Something like that should work, we might want to explicitly split up the latch event definitions and the every-cycle definitions.

 

The idea is that the latch event is evaluated via the type of the cart (right now I expect wed have ROMWrite and CRUWrite types). The rest is evaluated for every access, and to make defining them less painful, any pins not explicitly defined are pulled from the cart port directly (or in the event that latched address lines are defined, from those - latches need to be explicitly defined to exist).

 

Something like that does that make any sense?

[+Ksarul]

I like the approach, Tursi. It makes the definitions for each cartridge file create the environment that the cartridge needs to run in on the fly. That is definitely a good way to avoid a plethora of cartridge types that all do the same thing (even if they sometimes do it just a little bit differently).

[+mizapf]

Those MB cartridges Sewermania, Space Bandits, Superfly, do they have real GROMs inside or GROM emulations?

[+mizapf]

Those MB cartridges Sewermania, Space Bandits, Superfly, do they have real GROMs inside or GROM emulations?

 

It would suffice if you have one or more of these cartridges and send me a photograph of its innards.

[+Ksarul]

I'll have to dig around for one of them to open up, Michael. I'll send you a picture as soon as I've found one to open up. . .

[+mizapf]

@Tursi: Let's keep an eye on these ideas. No hurry, right now I don't have the cartridge handling at top priority; I still have a lot of open issues to fix first.

 

As for the definition of banking schemes, all is possible if we can get to an XML format at the end. There is some freedom to define properties using the <feature> element inside the softlist definition. A property-style declaration won't be feasible in MESS, though.

[Tursi]

I assumed XML:

 

Also, please disregard that I'm using INI format instead of XML, it's easier to type.

 

I've got a month left of exile, then hopefully I can get back to hobby stuff.

[Asmusr]

Isn't JSON what everybody's using these days?

[Tursi]

Not sure, which one is more bloated? That's probably the answer.

[sometimes99er]

For that matter, AtariSoft carts didn't use an external banking device at all, they did ROM and banking inside a single custom chip (or at least Defender did, that's the only one I've taken apart). So AtariSoft needs a different file type than the 379-based 16k carts...? Are they inverted or not? We actually don't know and can't easily find out -- you have no choice here but to guess.

 

Watch it. Defender was 8K only. Guess there's no banking.

[TheMole]

Not sure, which one is more bloated? That's probably the answer.

 

Actually, JSON is quite lean in comparison with XML and even compares fairly well to the .ini format in terms of bloatedness (although it is slightly less readable, imho). But yes, it's certainly the flavor du jour .