FarmerPotato
-
Content Count
1,464 -
Joined
-
Last visited
Posts posted by FarmerPotato
-
-
53 minutes ago, dhe said:Is this the manual your referencing?
http://www.bitsavers.org/pdf/ti/990/990-12/2268239_990-12Descr_Oct83.pdf
That is a short version of the one I recall reading. It's all in there somewhere.
Ah, here's the bigger one I remember.
http://www.bitsavers.org/pdf/ti/990/990-10/0945417-9701B_990-10_HWRef_Nov80.pdf
I must be thinking of the TILINE interface, which allows for memory transfers both ways between CPUs.
-
1
-
-
1 minute ago, mizapf said:The HDC9234 always uses DMA, but only to its on-board RAM. Otherwise, it would not be able to cope with the hard disk transfer rates.
Does the DSR just spin, waiting for the DMA to finish?
-
15 minutes ago, dhe said:You mentioned DMA. I know, the MyARC HFDC was the first to claim DMA capability, although, I also heard speculation that the MyARC FDC was on an evolutionary path to having DMA.
So how do you envision DMA working in the Geneve2020 - Covid Edition?
Aha, you are the first to confirm my fear, that 2020 no longer sounds futuristic. It is a year many will be happy to be rid of. Maybe I will just call it "2000".
The DMA feature will work just as TI intended. The essential is that a peripheral takes over the bus for a period, and has full access to read/write the other peripherals just like the CPU would.
This is fully described in the TM 990/12 theory of operation book (a good inspiration for me)
A peripheral issues a HOLD* interrupt--its sort of an interrupt outside the usual priorities. When the CPU completes the current instruction, it asserts HOLDA* and prepares to go offline in the next cycle.
It turns off all its outgoing bus signals (gets off the bus). The peripheral that requested HOLD* then can drive the bus.
A typical use of DMA is a disk controller that has its own microcontroller. When a disk controller has finished a read operation, say a command to read a bunch of sectors, it asserts HOLD*. When the CPU grants HOLDA*, the disk controller does a memory transfer. It copies the disk data from its own memory, into the computer's main memory. When it finishes, it releases HOLD*.
The CPU releases HOLDA* and goes back to its normal state. Or at least, that's how it works on the TMS9995. The 99105 does not have a HOLDA* output pin.
Instead, the 99105 outputs a 4-bit bus status code. One of these codes is HOLDA*. When this appears, an external circuit must remember that condition, because the bus status codes are one thing that vanishes 40ns after the CPU enters the HOLD state, when it gets off the bus. The external circuit puts the HOLDA* signal on the bus.
So I added that circuit. It's not working right--instead of initializing to 1 at startup, it gets stuck at 0. Because there is no transition of HOLD* from low to high, it is not cleared either (it is cleared on a rising edge of HOLD*, not HOLD*=1.) The external circuit remains stuck in the HOLDA* state, even though the CPU is never in that state.
So I put in a DIP switch to disconnect it if necessary. It's necessary!
--------
What is it good for?
Coprocessor
* If I put a separate 9995 in, it can be in charge of read/write bytes from the SD cards. It can copy from main memory, then do the write while the CPU does something else.
* Start up boot loader. If that 9995 asserts HOLD right after the 99105 leaves the RESET state, it can copy the BIOS ROM (maybe a 55ns FLASH part) into a high-speed RAM (10ns cycle). This is a technique introduced by the IBM PC. It may be necessary to let the 99105 run at 6MHz (and overclocked???) as the ROM becomes too slow to keep up. It's kind of hard for the 99105 to copy its own BIOS ROM into a RAM at the same address space.
* Fast block memory move. The 99105 can invoke an external instruction to move memory. The FPGA drives the process more efficiently than the 99105 could.
-
1
-
-
On 11/12/2020 at 4:20 PM, Stuart said:Did you ever get anywhere with this @FarmerPotato? I've just added a TMS9901-40 to my TMS99110 board (running at 4 MHz) and it works fine, in terms of programming the 9901 clock for 250ms level-3 interrupts. Just wired it in the same way as the 9902, and fed /INTREQ and IC0 - IC3 to the CPU.
I haven't gotten there yet. You kind of lit a fire though. I just got through debugging the 99105 to memory card at 3MHz, and I want to get the I/O working next, before cranking up the speed.
It's encouraging that you and Jim are testing these chips at higher speeds.
My prototype is shown over here:
-
1
-
-
1 hour ago, GDMike said:It's frustrating when you can't trust the wire wrap.
It's a delicate test environment, but what's a better way... don't think there is one.
Wire wrap is pretty good! In several respects, it is more reliable than PCB.
All the errors are my mistakes. For a while my printed WW layout was mirrored vs the real thing. (I found out Kicad can "print mirrored" to fix that)
-
2
-
-
49 minutes ago, BeeryMiller said:It's probably one of the yellow or blue wires, and if not them, then one of the red wires. 😀
Haha! love it.
OK, I removed some red and black wires, and put some on in different places. The blue and yellow looked pretty so I left them.
Getting cleaner! The last of the 3 WE cycles writes to 801E, which is R15 if WP=8000. Perfect.
The next RD is in bus state 3, IAQ, from address 0004. My source code says this should be PC=0008 and LIMI.
The next RD is in bus state 2, IOP, from address 0006. Immediate operand for LIMI.
internal ALU stuff
The next RD is in bus state 3, IAQ, from address 0008.
The next RD is in bus state 3, IAQ, from address 000A.
The next RD is in bus state 3, IAQ, from address 000C.
....
PERFECT!
That is, if my source was this. I must be looking at a newer src file.
aorg >0000 ws equ >8000 reset data ws,start start limi 0 nops nop nop ... nops ... b @nopsHere it is, looping around to the start.
State Addr 3 IAQ RD 0048 B 2 IOP RD 004A DATA >0008 3 IAQ RD 0008 NOP 3 IAQ RD 000A NOPYAY!
-
2
-
-
I'm suspecting the bus buffer chips again.
Measuring data inputs at the CPU chip (previously done on the backplane)
ROM image:
0000 8000
0002 0008
Most significant bit AD0 at CPU:
Values
0000 0002 AD0 1 0/1ish AD1 0 1 AD2 0 0 or 1 AD3 0 1ish AD4 0 1ish AD5 0 1 consistently AD6 0 1 most of the time AD7 0 1 most of the time --- AD8 1 1 consistently AD9 0 0 AD10 0 1 mostly AD11 0 0/1 AD12 0 1-ish should be 1 AD13 0 0/1 AD14 0 1 consistently D15_OUT Data bus at backplane LSB F0 F3At 0000, that matches the reading of 8080 . Look like AD8 is shorted.
At 0002, the ones are very weak and at any rate should not be there, except for AD12=1. Also AD8 is stuck.
At 0002, AD14 outputs 1 as the address bit, which is latched as LA14 and output as B_A0 (bus LSB)
Then it continues to be 1, when it should be 0.
Maybe it's the bus buffer chips, maybe not. This is the signal at the ROM, D3 should be 1 at addr=0002. Instead it's this crummy, neither 0/1, yellow mush.
After testing lots of pins, New finding. Some of the memory chip address inputs are unconnected. In particular, the ones that are supposed to be tied low or high always.
But A0 (LSBit) is supposed to be hard-wired to 0 or 1. One ROM supplies the even (MSB) and another ROM the odd (LSB).
This way, both ROMs can have the same image. (Yes, it halves the potential space.)
address Even Odd ROM data 0000 0000 0001 80 00 0002 0002 0003 00 08What I see is both ROMs driving >80, the value at byte 0000, so the word at 0000 is 8080. At 0002, the data is ... mush.
If the fix were as simple as tying the floating (unconnected) inputs to 0 or 1 finally, great. Unfortunately, A1 is shorted too, and I have to figure out where I made an error in wire-wrap.
This explains why the CPU is able to read 8080 from 0000, but gets random data from 0002. The floating pins tend to stay at 0, until a neighbor goes to 1, and then it's random. On the output, I measured 0s almost always where they should be, and mushy 0/1 where I expected 1s.
-
1
-
-
More progress
I continued going down the list of all bus signals.
I found that, even with RD* asserted, the CPU did not enable the input data bus buffer from the bus. This is the usual '645 ('245 style) with a DIR pin. It's because DMA was stuck on. That's right, I implemented DMA on the Rev 0.1 board (or tried to). Big mistake. It's broken.
Anyhow, I was afraid of this, so I included a DIP switch to bypass the DMA feature. Turns out I labeled and installed it backwards? Or the ON direction opens the switch? Open switch=no DMA. As soon as I flipped the DIP switch, bus activity exploded!
Still can't explain how the bus could be hi-Z, yet I still see valid signals on the backplane for MEM and Address and a lot of others. I can't make sense of what I observe.
I'm going to go on from here.
Glitches
Sometimes the scope enters a state of continually retriggering on RESET*. It is not a real RESET* though.
I see D6-D7 glitch low just as RD* or WE* fall, then rise. The glitch is over by the time the data bus must be valid. Probably a probe thing.
-
3
-
-
So, BST3 was just a loose wire.
The CPU is actually accessing memory now, ROM and RAM. It is not getting the instruction I put in ROM. I just have to keep slogging through checks.
The problem with the power draw that looked like a short, and the dead CPU with no signals, looks like this:
From power-on, no clock, and it draws 900mA.
If I touch the crystal pins with a screwdriver, the CPU starts clocking, and draws 400mA, and stays that way through repeated reset button-presses.
At power-on, it must be the internal oscillator that fails to get going. If all the NMOS gates are neither turning on nor off, but stuck in the middle--they draw the most current. The CPU is definitely the hot chip in this state. I'm going to live with this until I re-spin the CPU board.
----
Continuing BIOS memory card checks:
PSEL is high, indicating BIOS memory space, not the main memory.
ROM* select is active during fetch of WP and PC
RAM* select is active during store of R13 R14 R15
ROM* select is active during IAQ (instruction acquisition)
The bus has A0-A14,PSEL and D0-D15, where A0-A14,PSEL is latched and driven at the cpu card.
My address/data are numbered backwards from the TI convention. A0 is LSBit.
MSBit LSBit A14 13 12 11 -- 10 9 8 7 -- 6 5 4 3 -- 2 1 A0 x D15 14 13 12 -- 11 10 9 8 -- 7 6 5 4 -- 3 2 1 D0Address bus in memory cycles:
RD 0400 read WP from >0000 (ROM value >8000)
RD 0402 read PC from >0002 (ROM value >0008)
WE 849A save WP to R13 to >809A
WE 849C save PC to R14
WE 849E save ST to R15
I interpret this as: the logic analyzer is sampling a stuck bit in A9. CPU is surely fetching 0000, I see 0400.
But.. there is garbage (00 or FF) at real address 0400. Yet, logically, the WP was loaded with 8080.
So A9=1 must not be from actual A9. Yep, found that; probe A9 was loose.
Also if the WP=8080, there is a bad bit where D7=1.
If D7=1, then it also read a PC value 0088.
RD 04FE Instruction acquisition. What? we should be at PC 0088 at least. This is 00FE
Try again
RD 0000 read WP from >0000 (ROM value >8000)
RD 0002 read PC from >0002 (ROM value >0008)
WP 8080 internal set WP (yes!) .. uh, I see ALATCH FFFE, then 8080,929E,8080.. but addr should be latched. Huh?
WE 809A save WP to R13 at >809A
WE 809C save PC to R14
WE 809E save ST to R15
RD FFFE IAQ
Randomly alternating IAQ from PC 00FE or FFFE . Why?
Hooking up D7:D0 (now I'm about maxed out 32 probes)
I see garbage like FF, F0. It is not stable through one RD or WE. I cannot see it reading '80' from ROM, but somehow it is. Because the WP bus state OUTPUTS 8080.
Er.. how is it possible for "addr" to show 8080 if ALATCH falls with addr=FFFE? the address in the latch can't change until the next ALATCH. if the CPU outputs anything after ALATCH, it only goes onto the backplane data bus.
Between falling ALATCH and falling WE*, the data bus should match the addr bus.
Between falling ALATCH and falling RD*, the data bus should also match the addr bus, then the 245 switches to input. Once RD* and ROMSEL* are released, however, the data bus should be Hi-Z.
Two read cycles:
About the only thing I get from this is that addr=0000 and addr=0002 are perfect, along with RD* and WE*. Data bus is bizarre. But yet the value 8080 is being read!
CLKOUT has been glitched into oblivion.
Test ROM code:
Spoilerbiows equ >8000 intws equ >8020 lights equ >2200 aorg 0 data biows,reset data intws,int reset limi 0 mov @4,@>FFFC mov @6,@>FFFE nmi li r12,lights sbz 0 led loop limi 2 limi 0 * 128 nops. look for instruction >1000 nop ... b @loop int li r12,lights sbo 1 led rtwp endCapacitance on the oscillator pins...
On the breadboard the other day, I experimented with different added capacitance on the 12MHz crystal. A stable value there was 33pF. So I put 33pF on the cpu card.
Didn't change things.
I didn't know better, and on the PCB, I filled ground plane under the crystal traces. (I've already corrected that in the layout.) That's different (but how is it different from the crazy breadboard environment?)
Fact: The external capacitance on this oscillator needs to be large enough to achieve oscillation (amplifying a perturbance), but not so large that it decreases the resonant frequency.
Guess. When I attach the backplane, it changes the capacitance between the traces and the ground plane. But I'm not sure if it adds or subtracts. Empirically, it seems to subtract, because too little C can make an oscillator fail.
I think the ground plane pour, under the crystal, causes the XTAL1 and XTAL2 to be less coupled to each other, and more to the ground plane. So that's removing capacitance from the circuit to start with. So adding capacitance back in should be the right thing? Still, going up to 33pF didn't solve it, the way it did when I experimented on the breadboard.
I wonder how it changes if the backplane had its own ground connector? Right now it's just a big extension of the cpu board's power and ground connection. (Now waiting for the front panel/ATX power supply board from OSHPark, which will power the backplane.)
-
3
-
1
-
-
10 hours ago, Tursi said:What it didn't do, though, was clear the interrupt on the VDP by reading the status register. That happens at >0A84, only if QUIT was NOT pressed. Because the VDP still asserts the interrupt, when we come back around to that very first LIMI 2 I mentioned above, the VDP will seize and and force the interrupt to run again. It will loop for as long as you hold QUIT, and then finally run one more time before letting the reset actually finish. If you've ever pressed QUIT during an XB program with moving sprites and noticed the sprites speed up - that's why. It's just spinning the VDP interrupt as fast as it can until you release the keys!
I'm again amazed that there are so many things (for me) still to learn in this 35-year old console. Today it's why BLWP @0, or in TI FORTH, COLD, doesn't always work due to >83C4. And now, the reason why sprites speed up on FCTN-=!
-
3
-
1
-
-
36 minutes ago, jedimatt42 said:I would expect if one of the bus driver's is gone bad from your 6V adventure, that the impedance, while maybe not a full short would be very different from the good ones.
Depends on how hard it is to probe... You should be able to measure outlier impedance with the board off, outside the box. So that while tedious and time consuming might point at a single chip to fix.
If you are good with the ChipQuick and hot-air, then I would think removing one at a time until it livens up would be a winning strategy. If one is bad, then you'll have to anyway. You know it works when they are not connected.
I think I'd start (if they are clustered just right) with chips handling control signals, and save address or data lines for last. Addresses are outputs, and a cpu should still cycle on bad instructions from bad data.
The other thing you could do is reproduce the symptom outside the bus backplane... connect a pull-down resister to ground, and probe each of the bus outputs or inputs to see that they respond properly ( no effect, or desired effect if it is something like a wait state or reset line )
Just shooting in the dark.
I'll start checking impedance across ICs.
Thanks for the brainstorming -- one of those might be the right approach--I'll try stuff!
I just finished checking the backplane. There were a bunch of poor solder joints, but no shorts. I touched them up and De-Oxy.
Dadgummit... now the CPU is ticking. But the power supply temporarily went to 900mA. Then a normal 400mA. And now it appears I have broken my +5V power supply lead. Dangit. Going to have to repair that.
On a garbage instruction, the 99105 goes into MID interrupt 1110 and never comes out of macrocode 1001, but that's what it should do.
Bus states codes - see 99105 manual, or my copy of the table here:
https://gitlab.com/FarmerPotato/geneve2020/-/wikis/X.-Appendix-Reference-Tables#bus-status-codes
That document is my evolving reference manual
Being able to see the Bus Status in a scope.. that's really making this a pleasure to work on.
On the 3rd RD pulse. Bus status code 0010 is an Immediate Operand Fetch. Wrong. Should be a 0011, Instruction Acquisition. In fact, it looks like BST3 is shorted! Uhh
So, I'll look at what's going on with the '645 that has BST3 on it
-
2
-
-
Having tested all the CPUs in isolation, I am convinced my CPU was fine but some other chips are not.
I made a few additions to the CPU board. LS14 to debounce the RESET button, which was a simple RC rising signal before. Not because the CPU needed it (Also, the 99105 has its own Schmitt trigger on the RESET input.) But because I can't set an oscilloscope trigger without a nice clean edge. The trigger is where the scope takes a snapshot for you.
Anyhow the nice clean yellow edge, in the above post, was captured from the breadboard, and now the card can be triggered on that. Unfortunately, it took me all evening to get that soldered on neatly. But I got the same valid CPU startup sequence when testing the CPU in isolation.Prototype with ROM+RAM on perfboard.
The CPU is in slot 0. The memory card (in wirewrap) is plugged into slot 1. It lays down flat and covers slots 2-7. To make debugging easier.
The perfboard is covered by a sticky label, printed with all the signal names. It has room for both a right-angle and a straight connector to the backplane.
Now the real problem:
I no longer see any signals on the backplane, and current draw has gone from 350mA to 800mA. It's not the BIOS memory card, because I removed that--the current only goes down by an expected amount. Could be some buffers are fried from having 6V VCC. (though I'm not certain that I measured signals on the backplane before?)
Bus buffers are ordinary "sacrificial" LS245-type chips, '645 actually. They replace a '244 driver, too, when the bi-directional buffers are set to output one way only. It means I have one less kind of chip to buy. I hope that is not a bad assumption--the 645 datasheet says it can drive as many loads as a 244.
I'm not sure what I'm looking for--the CPU card works when it is not on the backplane, but goes dead when connected. Not even a CLKOUT. Just some impedance added to the buffer inputs/outputs, why?
Ideas?
- Check every line of the backplane, looking for a short, again.
- Check output voltage on every line of the backplane
- Build another CPU card (yikes. But you know why OSHPark gives you 3 boards. I got 5 from Seeed Studio)
- Remove chips one by one
- Feel for a hot chip with my fingers (that extra 600mA is going somewhere)
Reading
I learned a lot from this series, The Ultimate Guide to Switch Debounce.
https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1/
-
4
-
1
-
42 minutes ago, dhe said:Wait what? You mean, I'll be able to test memory, by removing it from a socket and swapping, instead of desoldering from a multi-side board, who's thru whole and traces are known to lift, from an ugly look? Wonderbar!
Yes, it is going to use real socketed chips, vintage, wherever feasible.
The Flash ROM and PLDs are all socketed (use inexpensive TL866 to update)
The SRAM does have to be soldered as it is 0.5".
I love the idea of popping out SIMM modules, when you decide you need to go from 8 to 32MB.
It became feasible when I found the connector at peconnectors.com and new modules sold at memoryx.com
And... our 11-year old built his first PC last month. Which means, popping in the CPU and the DDR4 modules. Just something so satisfying about installing what parts are still left for the owner to install. Since then he's been telling everybody who will listen, that they can do it, too. The funny thing is that the Dell PC case he was reusing, doesn't fit any ATX boards at all. So he's got a cardboard box instead. The cardboard box now sports one of the power button/wire harnesses that I just made for Geneve2020.
I'm procrastinating just now. Because I need to move corrections from the breadboard, into the real board, which means soldering bodge wire on SMD. No fun.
-
4
-
-
5 hours ago, dhe said:F Po,
How where you planning on doing memory?
I've thought, that with plentiful cheap SRAM, it would be pretty easy to do a board with a single 4 or 16MB SRAM chip and put a logic glue chip around it to 'throw' away the pages you don't need?
There will be some SRAM. These are 256K x 16 bits super-fast 10ns, and cost $4, so, SRAM is $8/MB. Vintage parts are 55ns (and... still $8/MB.)
I'm testing vintage chips tonight. The BIOS memory card has 256K SRAM and 128K Flash ROM. (70 ns parts)The main memory will be in removable 30-pin SIMM module pairs. The memory mapper will support 2MB, 8MB, or 32MB.
MDOS will occupy a 2MB slice.
-
1
-
-
1 hour ago, mizapf said:@BeeryMiller I remember this was indeed an issue ... but long ago, maybe 10 years or more.
I tried it with this code. The code is meaningless, also the CLR instructions.
I made a listing file so I could follow along more easily.
In the LI statements, I see:
LABEL1 0007
LABEL2 0016
LABEL3 0023
99/4 ASSEMBLER VERSION 1.2 PAGE 0001 0001 DEF START 0002 0000 45 TEXT 'Example' 0003 START 0004 LABEL1 0005 0008 04C0 CLR R0 0006 000A 0201 LI R1,LABEL1 000C 0007' 0007 0008 000E 41 TEXT 'Another' 0009 0016 04C0 LABEL2 CLR R0 0010 0018 0201 LI R1,LABEL2 001A 0016' 0011 0012 001C 4C TEXT 'LastOne' 0013 0023 68 LABEL3 TEXT 'here' 0014 0028 04C0 CLR R0 0015 002A 0201 LI R1,LABEL3 002C 0023' 0016 002E C0B1 MOV *R1+,R2 0017 0030 C0F1 MOV *R1+,R3 0018 0032 045B RT 0019 END 0000 ERRORS ~ ~ ~This would be a good opportunity, @GDMike, to practice the LIST file option in the assembler.
Use options RLS and you will get the L)ist file, plus the S)ymbol table
Exercises I recommend for @GDMike. I'm not giving the answers!
- Put in DEF LABEL1 at the top, and an RT before END.
- Put in a B @LABEL1 . Look in the list file at what the assembler puts in.
- In Classic99, open the debugger window. Set a breakpoint at the address of LABEL1 (which you find in the list file)
- Load & Run the program (you'll need that DEF LABEL1)
- Switch to the DISASM view, and use F2 to single step. What addresses does it B)ranch to?
- When there is an odd address in MOV *R1+,R2 what ends up in R2?
Granted that's emulation, but Tursi is pretty smart.
I put an RT at the end, and this code doesn't actually lock up. It executes some pretty stupid instructions that it makes out of the text, but it returns in the end.
-
1
-
12 minutes ago, BeeryMiller said:Will the Program Counter on real hardware allow execution of code on an odd boundary? I did not think it would allow that.
I know back when Geneve support was first added to MESS, I found one or two instructions that did not 'autocorrect' for an even boundary that then threw the emulated 9995 into executing code on an odd boundary. On the real hardware, the very same code did not allow that to happen.
Beery
The TMS9995 databook says the PC is 15 bits, word address. (page 5) So you cannot branch or jmp to an odd address-the LSbit of branch should just be dropped. JMP is in units of words as well.
Even though it has an 8-bit bus, it is still the 16-bit microprocessor inside.
-
1
-
-
On 10/24/2020 at 1:04 PM, FarmerPotato said:
All CPUs have checked out OK. Including J1, which didn't show up for this family photo. And even P1 is ok, that one that got 6V applied to VCC. (now I have to check other chips around it...)
-
4
-
-
So I've been testing the 99105 CPUs on a breadboard. This is hardware weekend.
I got two things out of the way:
The 99105 needed about 10ms between power up and making a stable clock. With RESET held low. So I made sure my power-up RESET input was delayed enough, and very sharp.
Also, the internal oscillator was doing poorly on a breadboard. I played around with the tiny (eg 30pF) capacitors until it got more stable. I also tried an external clock, which made everything smooth.
I am watching bus status codes at startup time. CLKOUT is 3MHz.
[Bus Status codes are 4 bits that reveal what the CPU is doing in this cycle. External memories and peripherals must parse the bus codes!]
The bus status starts at 1010 (RESET). The RESET state lasts three clock cycles. (the rest is theory...)
1010 RESET 1010 RESET 1010 RESET 1101 ST status register update due to interrupt 0101 INTA RD active during WP or PC fetch for interrupt. A14=0 1001 AUMS internal ALU operation, or macrostore access 1001 AUMS 0101 INTA RD active during WP or PC fetch for interrupt. A14=1 1100 WP workspace pointer update 0110 WS WE workspace transfer R15 0110 WS WE workspace transfer R14 0110 WS WE workspace transfer R13 0011 IAQ RD instruction acquisition (fetch) 1001 AUMS 1001 AUMS 1110 MID macroinstruction detect 1001 AUMS macrostore access ... infinite loop of AUMS, but not RD ...This sequence looks pretty good!
Since there is no memory hooked up, I consider this a success--the CPU chip looks ok. It just fetched a garbage instruction.
note: APP is tied to RESET, so it should be going off-chip for macrostore. Hmm.
A cycle begins with ALATCH high, important stuff happens after ALATCH falls, cycle ends with ALATCH high again.
RESET is yellow trace, WE is red trace (analog). There are a lot of glitches in the blue digital--I have learned to ignore them when they occur mid-cycle. I am pretty sure the glitches are an artefact of my logic analyzer cable and test pins. When I check them in analog, there are no glitches.
(Also you can see the CPU is drawing 193 mA.)
-
4
-
-
@BeeryMiller All, it's past time for me to say a big Thank You to Beery for all the support he's put behind the Geneve, going back to the beginning.
Without Beery's efforts, we would not have most software updates, or the source to MDOS. Also he published 9640 News for a long time.
-
4
-
-
3 hours ago, BeeryMiller said:If someone wants to ever add more information to the GenASM docs, I have the original Word Files that were used to generate those docs. Most of it is Paul's original text converted from a much older (unix???) document program, however the docs on the Video I think I put together on everything I could find/learn. There is an outside chance some of the XOP video opcodes could need an update as there were some things Jim Uzzell and Clint Pulley may have added or requested over the years.
Beery
Beery, I found the originals on whtech the other day.
whtech has GenREF in the .doc format as well as PDF. They are in http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/
inside GenREF.zip. In there is a README.doc that Beery wrote in 2004. It mentions the nroff format.
The early-access MDOS docs GENERAL, MEMORY, MATH etc (but not VIDEO) were in nroff format. Hey, just the other day those old files were in http://ftp.whtech.com/Geneve/GenProg/ but they are not now.
The original scans like 'GenLINK by Paul Charlton 1989.pdf' look to me like they were created using nroff.
Anyhow, Beery's doc and pdf versions supercede those.
If you have those nroff files, you can easily format them to your PC screen:
1. Download Cygwin64 tools. In the installer, make sure you choose to install the nroff package!
2. Open Cygwin command shell.
3. Navigate to your directory with 'cd /cygdrive/c/ti99/whtech/Geneve/GenProg' or whatever. (this is your C drive. use forward slashes)
4. nroff MEMORY | more
I resisted the urge to post digressions on nroff, LaTex, Donald Knuth...
-
I think first you read the Utility system calls doc in GenREF.
Then go to the MDOS src to learn how the task model works.
Tasks get switched out after a certain number of VDP ticks.
MDOS doesn’t use the 9901 decrementer but I guess counting VDP ticks is fine enough.
-
1
-
-
46 minutes ago, retroclouds said:That is most interesting. I wasn’t aware of MDOS being able to run tasks and its memory handling.
Is there a MDOS development manual where this kind of stuff is explained?
Suppose I want to write a Geneve native assembler program, then that would be very valuable information. Thanks.
Whtech. I put some links here yesterday.
-
1
-
-
1 hour ago, TheBF said:Sounds wicked complicated. Not good for my old brain.
Does anyone run it like an intel segmented model? (Code here, data there ,extra stuff somewhere else)
How does a 9900 type CPU deal with the extra 8 bits of addressing?
Is it in a hardware register somewhere?
You can use the small memory model of 64K until you need more. When you need more, you could implement overlays. It's a lot like SAMS.
There's no 8086-style segment registers in the hardware.
The TMS9900/9995 doesn't make separate code and data segments possible. The TMS99105 does--I'm reluctant to use it.
Geneve has an external memory mapper with 8 8-bit page registers.
A memory mapper is an external chip (see 74LS612 from TI. It's in SAMS). In the Geneve, it's a set of 8 registers, each holding 8 bit page number. Each mapper register governs 8K of the 64K logical address space. (TI prefers 16x4K pages, Geneve implements 8x8K pages.)
The external memory mapper in the Geneve works by taking the top 3 address bits (of 16). It gets the 8 bit page number from one of the 8 registers, which replaces those 3 bits on the wider bus. So the 16-bit logical address has become a 16-3+8=21 bit address for 2MB of address reach. Or, 256*8K.
The Geneve sends those 21 address lines across the Pbox backplane (after using them onboard, to address its own chips).
That's the physical address side.
In the Geneve, there are 256 physical pages. In the MDOS task model, each task has a table of 256 virtual pages. Physical page numbers are allocated into there starting at 0. The 8 mapper registers are populated with the physical page numbers. Either by direct write to the register, or an XOP call.
It's up to the task to decide, when to move a physical page number from its virtual map, into a mapper register.
But certain XOP calls (DSR) accept 24-bit addresses -- these are translated to physical page numbers by looking at the task's virtual page table.
That's just software.
When DSR needs to read or write data for the calling task, it looks up the task's physical page page and maps it in.
This would be better with some illustrations
Example
A task initially had 1 page or 8K of memory. The OS loaded it in physical page >99. So its virtual map is just [99,...]
The task asks for 15 more pages, to reserve 128K of memory in all.
Suppose it is handed physical pages >31 to >3F. (they need not be consecutive--fragmentation.) The OS puts them in the task's virtual table,
which is now [99,31,32,33...3F]
It's up to the task to move the physical page numbers into mapper registers. It could copy the first 8 into the eight mapper registers (page 0 must never change) That's a flat 64K memory model.
Or say you want to split it into 32K of always-present, and 32K of paged pages.
The task would move 4 physical page numbers from the first 4 virtual pages into the first 4 mapper registers.
Then it could fool around with the next four. It could use the top four banks to have up to 32K of its other 96K mapped in at one time.
Now it can ask the DSR to read in a whole file. It can ask the DSR to grab 96K of the file and put it at virtual address >8000. Or it could ask the DSR to go get 32K of some other file and put it at virtual address >18000. The task doesn't need to map this in. The DSR figures out how to get it done, and cleans up after itself.
Once the task resumes, it fiddles with its mapper registers to bring some of that virtual buffer space into some of that upper 32K.
*
It's not really a 24-bit address, just because it fills 3 bytes. There are really only 21 bits of address possible.
-
4
-
-
28 minutes ago, grayin99 said:Thanks for the info on the chips. Unicorn seems like a good place to find all of them. Only issue is the $30 min order. These chips come to about $5.
I just checked my inventory. I have 3 of the RAMs (the other stuff too). PM me with your mailing address and I will ship a set of chips out to you.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What if? Designing "Geneve 2020". Cool 3D views!
in TI-99/4A Development
Posted
Today I've got the CPU card accessing ROM and RAM over the backplane. It's running well.
The memory is on a wire-wrapped card, so I can evaluate the bus signals before sending off for a PCB. The WW version is quite simplified.
Today I also imagined adding a 9902 to the wire wrap board. Here is the kind of planning I do before starting WW:
It's made from bits of the main schematics, pulled into a new Kicad schematic. It's laid out in the kicad pcb, but intended for perf board. I try to label all the pins, and I can print all this on a sticky label. Not all the traces are drawn. The ones that are, try to follow a sensible path for pulling a wire.
As I build it, I highlight traces done.
Wire wrap forms a very durable system. They were typically used to make production units, until PCBs became very cheap and reliable.
And yet you can unwrap a wire and make changes just as easily. It sure beats lifting pins and soldering wires onto a PCB. In fact, you know the little wires you see as corrections on PCB? Those are made specifically for wire-wrapping. Wire wrap has advantages over breadboard. You need similar attention to cable management, but you can't accidentally unhook a wire.
====
This will form a minimal-minimal system. Once it's in a PCB card, I can't hack on it so easily. But it can run a BIOS and I can test communication over a serial port. With that, I can keep working on hardware or software while I wait for PCBs to get made.
The current roadmap:
Minimal system anticipated, made of 100x100 mm cards, on an 8-slot backplane:
*has PSU, fans, & keyboard/mouse connectors (for I/O card)
Will run FORTH language, has 256K SRAM.
A full system would also have:
Intended to run GPL and MDOS
In-between steps are:
Final system, made of 160x100 mm cards:
For a possible 4-slot system with no expansion, the video&sound might be combined.
That's the current roadmap.