acadiel
-
Content Count
2,104 -
Joined
-
Last visited
-
Days Won
3
Posts posted by acadiel
-
-
Why use the inverted outputs of the '379? Especially as there is programmable logic already on the chip. It makes coding a f**ing pain in the ass, quite frankly.
Legacy use. I found that most of the 16K ROM carts out there (i.e. DataBiotics) used it, so that's what I used.
-
I'm working to write a description of how the bank switching scheme works in the 512K cart. I wanted to run this by everyone to make sure I'm understanding it correctly so that there are no mistakes...
(I've attached a 74LS379 block diagram for reference, so we'll use it. I'll add the extra D4 and D5 lines to my final description for the 512K bank switch cart when I'm done.)
1) When we set up TI A0-A15 (the address lines) to read/write to the cartridge address space (>6000->7FFF), cartridge board pin #34 (ROMG*) is made LOW). If we are not read/writing from that space, it is HIGH by default. This is connected to E* (pin #1) on the 74LS379.
2) E* (pin #1) on the 74LS379 is enabled by bringing it LOW. Since ROMG* is connected to E*, when ROMG* is made LOW (i.e. cartridge ROM space is being accessed), this enables the 74LS379.
3) When enabled, the 74LS379 is now outputting data on it's *Q0 - *Q3 outputs (pins #3, #6, #11, and #14). By default (this behavior is not defined and there is no standard here), we get 1111 on those inverse outputs. (These are hooked up to A14, A13, A12, and A11 on the TI. A15 is not used because ??)
74LS379 (Active, Enabled, Power-up [Typical)] Any write from 0110 0000 0000 0000 (>6000) to 0111 1111 1111 1111 is valid to bring *E low. *ROMG A11 A12 A13 A14 A15 (TI PINS) || || || || || || L 0 0 0 0 0 (TI PIN VALUES) || || || || || || |==============================| | /\ /\ /\ /\ /\ /\ | |*E D3 D2 D1 D0 n/a |(74LS379 PIN INPUTS) | || || || || || || | |n/a *Q3 *Q2 *Q1 *Q0 LSB |(74LS379 PIN OUTPUTS) | \/ \/ \/ \/ \/ \/ | |==============================| || || || || || || n/a 1 1 1 1 n/a (74LS379 OUTPUT VALUES) || || || || || || n/a A16 A15 A14 A13 n/a (EPROM address lines)
4) When we *write* to the cartridge ROM address space, cartridge board pin #32 (WE*) is made LOW (It's normally active high). This is hooked up to the CP pin (#9) on the 74LS379. (Can someone explain how this whole CP thing works?)
5) When CP is LOW, this "clocks" the 74LS379. Whatever the 74LS379 is seeing on its D0-D3 (pins #4, #5, #12, #13) inputs (which is't getting from TI A11-A15), out puts the inverse output on EPROM A13-A16.
So, on a 128K EPROM, writing to the following addresses will do the following:
Address TI A11-A14 379 output, EPROM A13-A16 >6000 0000 1111 >6002 0001 1110 >6004 0010 1101 >6006 0011 1100 >6008 0100 1011 >600A 0101 1010 >600C 0110 1001 >600E 0111 1000 >6010 1000 0111 >6012 1001 0110 >6014 1010 0101 >6016 1011 0100 >6018 1100 0011 >601A 1101 0010 >601C 1110 0001 >601E 1111 0000
6) Let's look at this from an EPROM point of view with the above outputs from step #5:
128K EPROM has address space >0000->1FFFF A16 A15 A14 A13 A12-A0 8K #1 1 1 1 1 1111111111111-0000000000000 (>1E000->1FFFF) 8K #2 1 1 1 0 1111111111111-0000000000000 (>1C000->1DFFF) 8K #3 1 1 0 1 1111111111111-0000000000000 (>1A000->1BFFF) 8K #4 1 1 0 0 1111111111111-0000000000000 (>18000->19FFF) 8K #5 1 0 1 1 1111111111111-0000000000000 (>16000->17FFF) 8K #6 1 0 1 0 1111111111111-0000000000000 (>14000->15FFF) 8K #7 1 0 0 1 1111111111111-0000000000000 (>12000->13FFF) 8K #8 1 0 0 0 1111111111111-0000000000000 (>10000->11FFF) 8K #9 0 1 1 1 1111111111111-0000000000000 (>0E000->0FFFF) 8K #10 0 1 1 0 1111111111111-0000000000000 (>0C000->0DFFF) 8K #11 0 1 0 1 1111111111111-0000000000000 (>0A000->0BFFF) 8K #12 0 1 0 0 1111111111111-0000000000000 (>08000->09FFF) 8K #13 0 0 1 1 1111111111111-0000000000000 (>06000->07FFF) 8K #14 0 0 1 0 1111111111111-0000000000000 (>04000->05FFF) 8K #15 0 0 0 1 1111111111111-0000000000000 (>02000->03FFF) 8K #16 0 0 0 0 1111111111111-0000000000000 (>00000->01FFF)This means that the "low bank" (>6000) is actually your upper 8K. and the "high bank" (>601E) is at the very bottom of the EPROM address map.
7) (Not sure): When our read/write to the cartridge ROM address space is finished (i.e. the TI is talking to something else not in the cart space), E* (pin #1) on the 74LS379 is disabled by bringing it HIGH. Since ROMG* is connected to E*, when ROMG* is made HIGH (i.e. cartridge ROM space is not being accessed), this disables the 74LS379 from putting anything on its outputs to the EPROM address lines. (What exactly DOES happen, then, to those EPROM address lines?)
Hope this helps those who need help understanding bank switching, and hope that I can get some of the clarifications that I need in here (like how CP works, and my other questions I put in parenthesis).
Thanks, all!
-
Does anyone have all the op codes documented in order of op code?
-
Apparently, it looks like there are several 74LS logic chips, a GROM, two 2114 (512 byte) ROMs, and the ROM (can't find any specs on it.)
That would read: it looks like there are several 74LS logic chips, a GROM, two 2114 (512 byte) RAMs, and the ROM (can't find any specs on it.)
Where is the GROM located ?
I'm guessing the CD5256 chip is GROM. The other five on the right are 74LS logic chips, and on the left is the ROM and the 512byte x 2 RAM.
-
Apparently, it looks like there are several 74LS logic chips, a GROM, two 2114 (512 byte) ROMs, and the ROM (can't find any specs on it.)
Look at page 8, here. It states how MBX carts work: http://pdf.textfiles.com/zines/MICROPEDIUM/mp970304.max.pdf
"The MBX method is a semaphore method to switch the ROM bank. You write the bank number directly to location >6FFE. In any MBX module, you will find a RAM of 256 bytes. (Why is there 1K in this one?) This is decoded to ROM location >6C00 through >6FFF. So you can read back the bank number from this RAM, because it will be written in parallel to the switching register. Nice feature, but incompatible with all other banking methods. This is the reason, other programs will not correctly read out the ROM banks of MBX modules. You have to write 00, 01, 02, or 03 to the banking register."
Also, here: http://tech.groups.yahoo.com/group/ti99-4a/message/3078?threaded=1&var=1&p=2
MBX banking seems to keep >6000-6FFF static, while banking >7000-7FFF. The Gramulator accomplishes this with 20K of RAM, which I take to mean byte 1 values of >0B-0E make bytes 4,5 the value >7000. I am not sure how MBX
banking works.
BTW, here are all the MBX carts dumped (HSGPL format) as well as some example code used to generate the headers for them. There aren't any other places on the 'net that have these, so I'm sharing the wealth...
All of the carts are here except 3154 (Terry Turtle's Adventure). Also, PHM 3149 (Space Bandits) doesn't work. I don't think it has the proper header, because it loads as an autostart cartridge.
I haven't tried these in MESS with the HSGPL yet, but on a real HSGPL, to get these to work, all I did was this:
Load the files into bank >10
reset
Go into TI BASIC
CALL GRAM
CALL MBXON
bye
-
1
-
1
-
-
Actually, you might want to take the code from one of the old Funware carts apart and see how they got around the issue--they didn't have GROMs, but they did work on a V2.2 console. . .much to TI's dismay.They don't show under emulation (I tried Ambulance), suggesting it's not a pure software approach. Does anyone have pictures of inside one of these carts?
I think they eventually were licensed to use GROMs (were they the only "official" one other than Parker Brothers?) Lobster Bay and some of their non released games are in GROM format (not ROM) - I tried putting some of these in a ROM cart, that's why I know.
They did include this letter with some games, which makes me wonder if they re-did some games to run from GROM: http://www.videogamehouse.net/funwarenotice.jpg
-
Can a dead 99/4A non 2.2 console have the GROM0 taken out of it and put in the V2.2 one?
-
Arcturus (sidecar) did that. When I dumped it, I found it actually lived in the Powerup DSR space and in the >A000 memory expansion space. The power up DSR took over at the title screen.
Tursi helped with converting it into an EA/5 executable which we dumped in a module with the "copy to >A000 RAM and run routine". I think it helped that it was already coded to run in >A000.
Attached is the original dump, including the >4000-5FFF DSR ROM. Maybe it'll have something you could use.
-
2
-
-
The "128k" isn't the limitation in the menu program, it's the number of lines on the screen. (And that's a pretty weak limitation, I know
). In order for this to work, you'd need to have a different binary in each "segment" that scans a different range. BUT, you can certainly try. With a hex editor, you should be able to make versions that scan different areas of the chip. The range is entirely up to you, doesn't have to be 128k blocks, though I guess being consistent makes it easy.The >AA71, as you already noted, needs to be changed to make it show up. However, you have to change this in several places for proper behaviour - the menu uses this magic value to find itself no matter what bank on the ROM it's in. If it can't find itself it will crash since it switches away to read the other banks, and needs to be able to switch back.
So, I /think/ these are the changes needed:
Offset/Original/New/Reason
--Multicart tag
0000 / AA71 / AAxx / 'xx' being the tag you want to use for this menu, recommend not using 00-03, or 3F, stick to higher values
0A2C / AA71 / AAxx / same 'xx' as above - this is the code that searches for the multicart
0AEE / AA71 / AAxx / same 'xx' as above - this is the code that builds the menu (skip this multicart menu)
--Lowest bank switch value - minus two (so original is >6000 - 2 = >5FFE)
0A38 / 5FFE / 60xx / Lowest bank switch value to scan minus 2 (multicart search function)
0BAC / 5FFE / 60xx / Lowest bank switch value to scan minus 2 (menu building function)
--Highest bank switch value - use exact value (this is the 'HIGHEST' equate in the code)
0A24 / 6020 / 60xx / Highest bank switch value to scan (multicart search function)
0AE0 / 6020 / 60xx / Highest bank switch value to scan (menu building function)
Yep, 128K (and the current layout) keeps things nice, neat, and on one page for each "Multicart"
No new coding needed! <g>I'll make the changes you noted above and give it a try and see how it works with the 512K flash once I get the new board in, get the GAL programmed, etc.
The only thing I'm scratching my head over - 5FFE? (It's probably right in front of me, but I'm kind of stumped about the -2).
Edit: Can Classic99 bank switch 512K yet? I can just put the modified code in there before I get the board to make sure it works like I want...
-
Well, what I was thinking is just daisy chaining Multicart as a workaround just to make sure the banking is working properly for testing the new board (until you get time to recode).
You start by scanning all banks starting at >601E (I think) and working your way down to >6000. A simple change to the source, and I can tell the power up Multicart to include another Multicart at the bottom of that first "128K segment" (instead of ignoring it) as the last menu item on the show up on Multicart. The second Multicart would simply scan the next 128K range, and have a Multicart at the bottom for the third one, and so on.
I would have have to change the >AA71 header on subsequent MultiCart programs so that they show up, and just change the range (starting at >601E and below, >603E, >605E, and >607E).
First 128K segment:
>6000 Multicart (modified header so shows up, points to Multicart at >603E)
>6002
....
>601C
>601E Multicart (power up bank)
Second 128K segment:
>6020 Multicart (modified header, points to Multicart at >605E)
>6022
....
>603C
>603E Multicart (modified to scan this 128K range, >603E to >6020)
Third 128K segment:
>6040 Multicart (modified header, points to Multicart at >607E)
>6042
....
>605C
>605E Multicart (modified to scan this 128K range, >605E to >6040)
Fourth 128K segment:
>6060 Multicart (modified header, points back to Multicart at >601E)
>6062
....
>607C
>607E Multicart (modified to scan this 128K range, >607E to >6060)
Thoughts?
-
Can Multicart be enhanced to use the RAM to buffer the whole 40 something 8K ROM carts without switches now? (I think you said it was tight with the VDP scratchpad, so can we can offload it to the AVR now?)
-
The RAM is not CPU RAM, so it's not actually what people have been requesting (and only 8k is available, not 16k. It needs some of the RAM to run the emulation code after all!) The AVR always answers as a GROM. I/O is managed by reads and writes to GROM space, so it's like memory-mapped devices. The multiple data is handled through special writes that cause page-flips, so you can page the GROM, GRAM, EEPROM and devices in and out in real time. The only thing I haven't worked out to my liking yet is how to partition the GROM space to keep wasted space at a minimum while still being flexible on GROM sizes - the current code builds all the ROM data into the program.
Ah, that explains things - the RAM is for the AVR itself, not for our usage
Still, GROM/GRAM and EEPROM probably would give us a whole heck of a lot. Imagine Owen making a super mega Beryl RPG
:) -
(The Atmel chip, that is)
-
Oh yeah, and it does have 16K of RAM for those of you who have been requesting it. 4K of EEPROM and 128K of flash as well. Not sure how it all will be implemented yet though. Tursi's working on that part
-
Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins.
Anyone for making a TI megademo?
Here's the latest revision that Ksarul has been working on. This is still prototype stuff, guys, and yeah, I don't think you can cram much more on that cart board.
Onboard, there is a Lattice GAL16V8, that takes the place of the 74LS379, but lets us bank switch 512K (adds two more sets of I/O lines) in the 49F040 flash ROM. Thanks to Matthew, we have the code needed to burn these, but haven't actually burned one yet. No worries, it should work. Ksarul took the pin output that Matthew provided and used it, so as long as we don't make any changes, the pins should be fine.
The ATMega 1284 is the GROM emulation, and you can thank Tursi for that work, he's done a great job, and proved it at last year's TI Faire with his demo. There's a bunch of I/O jumpers to interface with the ATMega, so just about anything is possible. That's a pretty powerful AVR [8 bit RISC] for the machine it's interfacing with! We can do GROM, GRAM, the thing has some EEPROM as well as Flash, you name it...
And, also thanks to Ksarul, we have a boatload of 49F040 Flash and GAL16V8's for parts.
I'm anxiously awaiting the next prototype board run to see how well it works
-
1
-
-
I have what was on the WHTech site, plus a lot more I added, including all the ROM ports, such as Arcturus, etc. (Sort by date to see what's new.)
Caveat is that they all should be distributed freely, all copyrights belong with the authors, etc.
fredcarts-cf2k-dm2k-du2k.rpk
cf2k20-final.rpk
Miner.rpk
Espial.rpk
Killer.rpk
DU2K20-final.rpk
DM2K24-final.rpk
Arcturus.rpk
tiworkshop.rpk
tris2.rpk
spacepatrol.rpk
facechase.rpk
mancala.rpk
greatwordrace.rpk
dragonflyer.rpk
supermodul.rpk
pitfall.rpk
neverlander.rpk
-
I'll defer some answers to Tursi and Ksarul.
About the F chip - Ksarul got a large (and I mean large) lot for dirt cheap. So that's the story behind that.
Don't know Tursi's plan for programming the AVR, but he's got those pins in the front for something. I know that most of the AVR pins needed for programming are being brought to the front of the board.
As for jumpers, it's a 512K chip. That's what you get. 512K. Don't know if there are any plans in the prototype to change it. Since Ksarul got such an amazing price on those 49F040's, you can simply fill up the part you need andnleave the rest available.
Anyway, I've spilled all the info (or misinformation) that I have right now.
And unless I'm wrong, apparently (?) with GROM emulation and the banked ROM, we might be able to use these boards for a new XB.
I'll shut up now and let the experts chime in.
-
Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins.
Anyone for making a TI megademo?
-
I looked at the PCB layout over lunch. It's a good looking board !
I am assuming these things, am I correct ?
JP1 has pins 1 & 2 tied together for WE. You didn't state that the jumper had been made but I am assuming it has and I imagine it needs to be to drive WE HIGH. If unconnected then it would be floating and could cause you grief.
JP2 has pins 1 & 2 tied together for *OE
ROMS drives the *CE signal directly from the TI ?? (this is how it appears.)
You know, Marc... I owe you a few beers in Chicago. JP1 was the culprit.
(they didn't have a facepalm smiley) I've been banging my head on this board for quite a many months (try late last year), even sent it home with Tursi from Chicago. +1 for crowdsourcing help on the Internet!!! I soldered Tursi's cap back on, put two switches, reinstalled the 22pf caps, and the thing works beautiful now.
You can thank Ksarul for remapping the board and putting a 512K chip on it. The next iteration has a GAL slot instead of the 74LS379 along with the 512K ROM flash. Yes, 512K of bank switchable cart space (not 128k x 4 like this one).
I need to buy an ATMega 128 now and have Tursi put E/A and some other GROM-only stuff on it (Demo, whatever - how many can I cram on there with REVIEW MODULE LIBRARY?) and test it out with the ROM installed now. Tursi, do you recommend a particular programming kit for the ATMega stuff for a hobbyist? I found the Mouser URL for what I think is the chip here.
I'm excited!!!! (And I need a long vacation. Work is killing me, so I'm surprised I'm still sane.)
-
Man.. I leave for work this morning and there are no replies, and then come back home from work, and wow....
OK. Here's the deal: No Microcontroller on it right now. Just the 49F040 FEEPROM and the 74LS379.
Tursi thinks it might be power draw.
As soon as I get more time tonight, I'll reply a little more in depth.
-
I'm going to try a little crowdsourcing here for the last version of the cart board that Ksurl, Tursi, and myself have been working on.
I've attached a zip file with two ExpressPCB files in it - a v4a (which is what the 512K Multicart working version is made from), and a V6d, which makes it a PLCC FEEPROM instead of a DIP EPROM.
The V4A board works great - I made around 10 prototype carts with it and an EPROM that Tursi and I worked on (has almost all 8K ROM carts ever made for the TI in it). It works by bank switching 128K x 4 with the help of two switches and Tursi's Multicart program (runs on an unexpanded TI, too!)
The V6D board - well, it's been kind of a bear. I've looked at it, Tursi's looked at it, and I don't think we've gotten far in the past year on it. I've flashed multiple AT49F040s on the V6D board with the same binaries that I burned into the 27C040 on the V4A. Verified them multiple times.
When I power up the V6D, I can now usually get MULTICART to show up (which means it's doing the right thing and powering up in the last bank), however, I am still getting quite a few lockups. Sometimes, Tursi's MULTICART logo (and "Made by Tursi") show up, and nothing else. Sometimes, I get a lockup and blank screen. Sometimes, I get the MULTICART logo and Made by Tursi as well as a list of around 7 or less programs and then a lockup.
Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).
I have a V6D board here, so I'm open to trying whatever with it. The only jumper I have is the one between pins #1-2 of JP2.
Also, the AT49F040 has a different pinout in the PLCC32-DIP32 adapter so I can't try the flash chip on a V4A board; however, like I said, it verified multiple times in my 844USB programmer.
Thanks, guys!
-
Just FYI, I finally got around to ordering a replacement jack.
I'll let you know how it works out.. pinout looks identical, but I don't have a micrometer handy, so the spacing might be off. Stay tuned.
Got the replacement jack in from Mouser. The through hole pattern and jack size was spot on. However, the through pins were a little large for the hole in the MBX PCB. Nothing a 3/32" drill wouldn't fix. A quick desolder job, followed by the drill, and then the soldering of the new jack seems to have worked great. I have a spare now too, since they were so cheap (I do have a second MBX somewhere in a box.)
I also had to take a cm or so off of the ribbon cable that comes from the keypad matrix on the front of the MBX with some scissors. The contacts weren't making great contact with the board once inserted, even after a good pencil erasing. Still have plenty of slack.
The only other thing that I might wind up having to do to get this thing completely working (100%) is make a new cable for it - I think there's a short in one of the DB9 connectors. For right now, the kids are playing "I'm Hiding" again and are ecstatic that it's working properly for once!!
I suppose it's time to play with the hybrid GROM/ROM cartridge board now.... :-) Tursi, I'll burn another flash chip and make sure it works and see what happens on the board again.
Jon
-
Man, I am stoked about this... awesome job, Matthew!
-
The power *PLUG* (the part connected to the power cord) is a standard 5.5mm(OD) x 2.1mm(ID) positive tip (inside is positive).
That helps me out. I'll buy a new jack (yes, the jack inside the unit is broken) from Mouser that's 5.5mm (OD) and 2.1mm (ID).
Thanks, Matthew!!
Just FYI, I finally got around to ordering a replacement jack.
I'll let you know how it works out.. pinout looks identical, but I don't have a micrometer handy, so the spacing might be off. Stay tuned.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Walking through bank switching
in TI-99/4A Development
Posted
I think that Ksarul put an invert jumper in there for the new GAL, if I'm not mistaken, but he'll have to chime in.