brain

brain, on 01 May 2014 - 12:10 AM, said: By incrementing the address after every read or write operation - also whether the GROM was the one being addressed or not. Perhaps I misunderstand the question? <brain>The statement on the page says "every operation", but I think it should say "every data operation". The counter does not increment on a address read or write.

How does your AVR handle: "The counter will be incremented after each operation, whether it's a read or a write." from http://nouspikel.group.shef.ac.uk/ti99/groms.htm To clarify, I am assuming that only data read and writes cause the address counter to increment. So, if you do a write 0000 and then a read address, you get 0001, not 0003 Also, on the internal flip flop (and variable in your code), how does the system handle: "Any data access resets this flip-flop to "first byte expected" TO clarify, to read a word, you read 2 bytes. How does the GROM know *NOT* to reset the flop/variable on the second data read? Jim

OK, I have a TI MultiPlan Cart that works, and I popped it open and it looks like it has 5 GROM ICs (At least I think so, the ICs seem to map the required signals on the cart port, and they are short too many pins to be a ROM. I was thinking I would write a small AVR program to dump them and then wire up a M1281 with your code to run Multiplan, mainly to check out your code I assume multiplan is already dumped somewhere. I want to dump this cart myself so I better understand GROM access, but it'd be nice to get a copy of the BIN file to verify my dump output. Jim

Thanks for the explanation. So, GROMs are byte addressable, in that the GROM address space is 64kB, not 128kB. And, 5 GROM bases are available for each of the 16 GROM banks. So, assuming you are copying two apps, who both use GROM base 3 of GROM bank 0, how does the AVR decide which GROM data to send for GROM address 0x6000-0x7fff? Is there a set of select pins on the AVR to twiddle to pick which chunk of data shows up, or is GROM code locaiton independent? Jim

Understood, but I though the GROM address space was 64kB, thought it makes sense that it is a 64 kiloword device. I was basing my notes on the AVR code, where the read address sends the GRMADD>>8, but GRMADD>>9 would be expected for a 128kB address space. Can you note the 640kB math? I see 16 8kB carts, which is 128kB of cart space. With bank switching, it looks like you could have megabytes of space...

For those new to things, is there some calcs behind this? I assume 1 GROM "slot" per game, and a GROM slot can be a maximum of 8kB, which is 16 GROMs on a 1284, meaning 16 game slots. But, I must be wrong, and I don't know where I went wrong. Jim

Thanks, that helps a lot. For the newbie, here are some comments, use as you see fit: The blurb doesn't initially note that the device has an internal 3 bit "bank" and 13 bit address space. The note about carts having 5 GROMs seems incomplete. I assume you mean that 5 is all that can be placed in a cart since the first 3 "banks" are represented by GROMs in the console. Elsewhere in the forums, there are references stating that one could "override" the internal GROMs by putting a GROM at bank 0 or 1 or 2 in a cart. But, if I understand things, the "override" would cause 2 GROMs on the GROM address range to be selected at once, which would force their drivers to "fight" for the bus. Say, for instance, internal GROM at bank 1, byte 0 hold 0x55 and GROM in cart at bank 1, byte 0 holds 0xAA, when byte 0 is read from bank 1, does the databus get 0x55, 0xaa, or 0x00 or 0xff? In any event, it seems like it would smoke ICs. Jim

Thanks. The link does not appear to work. Does it have a typo? http://www.floka.com/grom_gnusb.html Wow, that is bizarre! So, when the GROM access occurs, there is a gate that enables the GROM GRDY line to the HOLD line (which initially HOLDs the CPU, and then it goes READY when the data is available, and then the line is disabled when the access is finished. Is there a LA trace of this behavior? In the day, I can see it being important, but now, not so much. It makes sense on the AVR, I guess. Hmm OPERATION: PORTA GRMADD PORTA = GRMADD >> 8 ) ; 0x62 0x6234 GRMADD = GRMADD & 0xff << 8 | GRMADD & 0xff; 0x62 0x3434 PORTA = GRMADD >> 8 ) ; 0x34 0x3434 GRMADD = GRMADD & 0xff << 8 | GRMADD & 0xff; 0x34 0x3434 So, if you do a read address after doing a read address, you get the above behavior? Man, that seems strange (and wrong :-) ... I saw the other forum posting. No worries. It's OK, I was just wondering if it was necessary to even implement the line if you were faster than the clock speed. Didn't mean to waste folks time. Just curious, as Eric and I were talking about the GROM, and all I could think of was a neat CPLD project to learn more about PLD programming... Mainly, a CPLD that converts a GROM footprint into a regular address bus. Input would be D7:0, GRDY, GSEL, MODE, MDIR, and outputs would be A15:0, D7:0, R/!W,!CS. Pop in RAM/ROM/FLASH of choice... I've got a 99/4A sitting here from the 2013 ECCC/VCF-MW show that I should play with, and I thought this might be interesting to get some time on it. Jim

http://www.floka.com/grom_gnusb.html (Your code)

Is there a document that explains GROM operation available anywhere? I'm not a TI-person from long ago, but conversations this weekend with Eric showing off his TI units at the Midwest Gaming Classic and the description of the GROM piqued my interest. Looking at the gnusb AVR code, it seems that: GSEL: Active low enable MODE: (high is address, low is data) MDIR: (high is read, low is write) D7:0 is data (reversed from the industry norm. GRDY: (low is ready for data, high is not ready) I understand READ DATA (just dump data from current internal address counter to data bus and increment internal address, wrapping aroung at the 8kB mark), but read and write address seem odd to me. Do you issue two write address cycles (MSB first) to load a new address? The AVR code does weird things during a read address. (GRMADD = ((GRMADD&0xff)<< 8 ) | (GRMADD&0xff) ; ) If I remember my C correctly, that says shift address left 8 bits (which makes the low 8 bits 0 and then (or) the last 8 bits (which are now 0). That seems odd, as it would be hidden by a second read address command (which appears to do GRMADD>>8 to output, but if a read data happened on the second read address cycle, a wrong byte would be fetched. Do all GROMs increment their internal address on a read cycle? I assume they do, but throught I would check) I'm still grappling with pages and slots and such, but (translating it to C64-speak), looks like there are 8 GROM banks (00-1f,20-3f,40-5f,60-7f,80-9f,a0-bf,c0-df,e0-ff on high byte of address) and each bank can have 8 sub-banks (x0,x2,x4,x6,x8,xA,xC,xE). On GRDY, is there any value in bringing this high? Namely, if a read access always occur in <500nS, will anyone see this go high?) Jim

The uIEC/SD (without the daughtercard) is designed to go into the smallest Hammond Case. Bug me if you can't get a link, and I'll look it up. The idea is that you would put on a 1x13 edge connector, and solder up some IEC cables and switches and power. I have seen lots of folks put the uIEC/SD right above the cassette port on the C64/VIC/C128/C128D. That requires no drilling and cutting, but allows internal mounting. The UIEC/SD was originally designed for the 64DTV, which is why it is so small and I designed it in two halves (unit and daughtercard). Jim

The 23256 ones are easy to use in a programmer (they use the 27128 pinout), but the 2364 ones require an adapter. I recommend using the 2364Adapter board from my site in reverse (put a header where the socket normally resides, and vice versa. Beyond that, only the pigtails for the upper address lines and Vcc need to be considered. Jim

I think all of this has been sorted out, but for the record: You do not need to buy the binary separately. Daniel buys the binary from my store since he creaes his own IC, a 3 KERNAL option. The official manuals are at http://www.go4retro.com/products/jiffydos/. If there are questions, there is a contact link on the page. No, it completely replaces the original IC. Jim

It looks like WE and A14-A16 are just routed to solder-pads (the schematic also shows A17?) and the board doesn't contain any additional logic. So, basically, this is just an adapter for using 128k flash chips (which are otherwise 32-pin in DIP) in a 28-pin DIP socket. so long, Hias This is true. However, I have often been asked for a variant as you describe. It could be done by: Adding a '575 on the bottom as a bank register, hooked to the data lines. three flying leads (/reset, bank register and /W). If that would work in the environment, I can see about a unit like that. I *might* be able to put 2 '688's to refine the select line a bit further, if that helps. JIm

Because surface mount assembly requires a "stencil", and I thought later on I might need to use 256kb or 512kb ICs, I added the additional lines. Jim

Impressive! Jim, RETRO Innovations

CBM-Command is recommended by many Also, please consider checking out the uIEC-users Google Group, for more information on usage. Jim

I was not specific enough. square post headers (the cheapest and most common) will ruin leaf sockets. Correct, but I tend to discourage any headers, because the nuance of machine pin versus square pin is tough to get across, and inevitably the wrong one will be selected by the person asking. So, in essence, if you need to ask me what strip header to use, I am going to say none. :-) Jim

Pin headers will ruin leaf IC sockets, and will not fit in machine pin IC sockets. On the 2364 Adapter, there are 4 holes on the side of the adapter. By attaching wires to the holes, and attaching 3 switches to A13/A14/A15 and running the other end of each switch to the ground wire, you can select one of 8 8kB "banks" of the EPROM. Jim