FarmerPotato
-
Content Count
1,465 -
Joined
-
Last visited
Posts posted by FarmerPotato
-
-
On 12/14/2019 at 1:42 PM, BeeryMiller said:As far as XOP's and interrupts, please keep in mind programmers have approached multiple routes for some of their programming. Some programs using the XOP's to do/get video data and keyboard data, while others go straight to the ports and bypass the XOP's all together. Some even mix things up depending upon the needs or what worked for them at the time. I'm not sure how your "Supervisor mode" would interact in these situations
Your first task should be to get an unmodified latest version of MDOS running. If you accomplish that, then everything else is bread and gravy and existing programs should work. If it is not possible to get the latest MDOS version running "as is" without modification, then there are going to be many programs that will not run and I would question how many people would actually jump on board..
All these are still definite goals in the plan.
I've worked out a design for robustly supporting memory-mapped access to ports in GPL and MDOS. Existing XOP or user code will find the ports there, but, XOPs could be rewritten to optimize. At the same time, all peripherals can be reached on the CRU parallel bus. In Supervisor or BIOS mode (or native FORTH or Unix or...) I'm trying to keep everything on the 16-bit bus pure memory, while using CRU for all peripherals, like a TI 990. However, depending on mode bits in the FPGA, any address in any page can be carved out as a port, not RAM. Or a CRU parallel range can map to a VDP port or other 8-bit device. (CRU parallel uses 8 or 16 data lines in one CRU cycle.)
An exciting feature that this enables, is that a GPL window at >4000 can be opened up to access an external P-Box (or any 21-bit address out there from MDOS.) This will require a new flex card. Or >6000 is opened up for real cart access, instead of just accessing a memory image or the GROM simulator.
I made a new block diagram that shows the relationship between a "native" 16 bit bus and the 8-bit peripherals (including cart port and P-Box.)
So, all XOPs and direct port access should "just work" when running an original MDOS binary. The BIOS will set all the mode bits before transferring into MDOS.
On 12/14/2019 at 1:42 PM, BeeryMiller said:As far as a cartridge port, myself, I am not particularly keen on a cartridge port. Are there really any cartridges that users wish they could run on their Geneve? Outside of potentially DragonSlayer and perhaps Matt's Finalgrom cart for the TIPI, those would be the only two cartridges. From what I read, it took the developer several years to reach the point where it was ready for release. Is there really any other ports that would be in cartridge form only that would be used on the Geneve 2020?
I don't want to exclude anything that comes along in the future -- therefore physical ROM and GROM will be accessed through one of the 8-bit slots (well two.) Also, I really want to plug in physical things. And this would make CSAVE very convenient (as if everything isn't dumped already...)
All the 8-bit peripherals will likely be separate cards. If you don't need one of them (cartridge.. sound card.. second VDP..) you can leave it out. I'm doing this so I can revise (or deliver!) each peripheral one at a time. So, you could just omit the cartridge port hardware. The P-Box interface is at the bottom of my list, but I consider it essential to provide access to existing disk controllers.
The architecture is looking more like a PC that has some 16-bit slots (AT) and some 8-bit slots (PC/XT). The two backplanes are generic, so, I could easily make one longer with more slots. Or a short (4") one which would be very cheap. The CPU is a plug-in card as well. Repairs or updates will be easier.
Thank you for your feedback during the design process!
-Erik
(Block Diagram follows)
-
2
-
-
3 hours ago, humeur said:look this manual.
I did not put all those I had with this new presentation, some are more European side
Jean louis
I will always love this game, just the way it is (it was my second module!) Lately, this cover has really fired my imagination. No promises.
A friend of mine, in Canada, has been trying to find this cover for ages. He collects car battling games in the pretty boxes. (Autoduel etc)
-
I clicked "Nope"
My collection is open-ended--not a goal I'm trying to finish. I'm always browsing to see what comes up for sale, then deciding if I want to jump on it. I try to buy the new hardware that comes out!
I find weird items I didn't know I needed. And some "normal" stuff. In the past year:
- Another TI-99/4 Zenith TV monitor
- A floppy drive and XT keyboard for my Geneve (Tim fixed it all up, thanks!)
- TI's "Le Clown Magique" (Amanda fixed the broken solder joints, and I identified the speech chip). It is a frightening sliced clown head that speaks French. We have the English version, Clarence.
- Some TI Watches
- A genuine TI dust cover
- A CC-40 and Memo Processor
- Lots of genuine TI chips (DRAMs, 99105, 9902, TMS5220C etc)
- Another Samsung 910MP monitor
- I was gifted a CF7+ from Charles Good (through Jim Fetzner) because I fried my NanoPeb just before my Chicago TI Faire demo.
I'm always looking for TI-99/4 era things to fill out my collection. Black Modules, working sidecars. Finding a Thermal Printer is something I never thought about, but I would go for it now.
I still haven't gone for a FinalGROM.
-
On 4/18/2020 at 11:11 AM, Gip-Gip said:Don't even get me started on raster engines, implementing one of those with the TI's lack of floating point and signed multiplication/division is a lost cause, and should never be attempted lest the programmer goes insane
I like your rendering engine so far. It does at least as much as Tunnels of Doom, and it's snazzier than dungeons in Ultima 3 (on apple ][)
What would it take to subdivide the grid, adding finer resolution? Instead of 2:3:7:3 sized wall segments, maybe draw 1:1,1:2,3:4,3.
And can it be graphic chars? A set of 8 progressively darker (more black pixels) tiles would do a lot to create depth. The diagonals would not look as pretty though.
-
4 hours ago, Kchula-Rrit said:I had often wondered that, since file I/O is through the DSR, is it an absolute requirement that file-transfers go through the VDP? It seems to me that transferring DEVICE<=>RAM BUFFER<=>VDP<=>CPU RAM makes for a pretty slow system.
That's the way it was on the 4A, which would not have any significant CPU RAM.
A revision to the file spec for later (never shipped) home computers remedied that. The PAB is extended and it has a flag for whether the destination address is in CPU or VDP RAM. But that's not our world.
-
1
-
1
-
-
P-Boxes
I've been thinking about how to connect a P-box to Geneve2020.
The need for this is to preserve the usefulness of your existing hardware. Disk drives, speech card, RAMdisk, TiPi, you name it.
I don't think Geneve2020 is a good fit for the inside of the P-box--it would take up at least 5 inches of width if I did that. So I think a new flex-cable card is the way to do it. You could move a P-box backplane into a PC tower along with the Geneve2020.
Flex Card
The new flex card would drive the 5 additional address lines ADA...ADE. It would have a nice round cable, like the more fashionable Ultra ATA or SCSI cables.
Like this: http://www.cablesonline.com/3cnmaltocnma1.html
50 pin SCSI cable should be enough--there are 40 active signals, plus you need a bunch of ground wires. You can choose your length.
The 16 to 8-bit multiplexer would be on the Geneve2020 end.. I don't think there is any use for a 16-bit bus reaching the Pbox. Right now, it seems to me that the Geneve2020 end is a 4x4" plug in card, while the P-box end is a traditional card size (less is not mechanically stable?)
Of course, going P-box would be optional.
How to combine old and new
1. Some software peripherals will exist onboard Geneve2020. Obviously, memory expansion is onboard, because 2MB is cheap. Speech is another--TMS5220C onboard (slightly incompatible).
2. You would write in your config file which pages you want to open up as windows into the physical P-Box 2MB space. For instance, enable Pbox RAM expansion pages (but why?) or speech or TiPi.
3. You would also configure which CRU ranges go to the physical P-box. If it's kept onboard, it reaches a new or re-created peripheral (say onboard RS232). If it's off-board, the CRU cycle goes out to the Pbox. For instance:>1000 either a Master DSR for MDOS onboard, or a mixture, or even a window to the Personality card (WDS1) if you have that.
>1100 either an emulated DSK1 (think CF7A+ format volumes on SD card) and HDSx, or an external controller.
>1300 either the onboard serial ports, or passed through to the Pbox.
>1x00 always-on access to SD card devices: SD1, SD2 or such. Regardless of whether they are mapped onto DSK1,DSK2 etc.
Enabling original DSR ROMs is a goal here, especially (only?) in GPL mode.
Enabling the MDOS Master DSR to see the real hardware is another goal.
I have a simple scheme for creating all this magic. The FPGA has a signal, I am calling it RDBENA for fun. When RDBENA is asserted onto the 16-bit bus, the FPGA owns the current cycle, suppressing all other cards. When it is not asserted, other devices on the 16-bit bus can interpret it. Put simply, the FPGA recognizes the start of a CPU memory cycle into address space that it "owns" and asserts RDBENA.
This is how I make the actual BIOS EPROM/RAM chips appear in the whole 64K at startup, while the FPGA can suppress those chips while in MDOS or GPL modes. (Even so, the 99105 can assert its own PS bit to seize direct control of the 64K space and suppress the FPGA. Interrupts do this. LDS and LDD instructions facilitate moving memory between these spaces.)
Similarly, the CRU address >1300 could be "taken over" from the physical serial port. It could point through a UART into the hidden super-debugger FORTH prompt, all controlled from within your favorite terminal software. Or it could pass through a window onto the physical P-Box.
If the FPGA sees that a particular memory access is inside a configured "window" to the P-Box, it simply lets it through, not asserting RDBENA. It's then up to a peripheral card (the flex card interface) to handle it.
Sharing
Getting data from physical floppies or HFDC in the Pbox. How would this work? You would want to be able to copy from physical devices to SD and vice versa. One solution would be to read files from a physical WDS1 or DSK1, and write to SD1, or vice versa. With emulated DSK not active.Another is to run two copies of MDOS at once, with one of them set up to access the P-Box, while the other MDOS image is running without Pbox devices. Some magic moves data between them, or they just communicate through files...
More Magic
In fact, you could configure any pages as windows into physical space, RAM or not. For instance, to choose what pages are RAM to MDOS. And whether the GPL cartridge page(s) goes to an image loaded in RAM, or to the physical cartridge port!
Pages are just a map to translate # 00-FF to a wider register in the FPGA. A read or write to any address is translated to the thing this register points to. Nothing has to be hard-wired. The 2MB MDOS space is already "sandboxed" virtually somewhere inside the 32MB maximum RAM, with its page numbers loaded with a code pointing to physical RAM. MDOS never knows about this -- only the BIOS knows this when it sets up an MDOS to boot (and it could boot more than one into memory simultaneously.)
Why Physical P-Box Cards?
I don't want to build a physical disk controller! SD card is what I'm focusing on.
I don't know all the use cases! I'm not going to close everything off and say "if you want to have X, it must now be emulated in new code plus magic." This was Myarc's error, not to facilitate standard DSRs. Meaning all your devices had to be re-created in MDOS master DSR, until ROMPAGE came along. I would prefer that all the real cards work in GPL mode at least. (DSRs are obviously written for the GPL environment.) I don't even want to try to know about and plan for everything.
Hey, I don't see why you would want to use your physical memory expansion card, when onboard RAM is 32MB. But knock yourself out. A RAMdisk? Why not, if you have all your favorite software already loaded there? A print spooler? RS232? Maybe sometimes. TiPi? For sure. (Though there will be a way to integrate TiPi to Geneve2020 -- its too important.) SAMS? Well... memory is cheap... (emulating SAMS will be a cinch.) AVPC? Why not? SID master? Doh! What others?
Maybe the physical cards are always just more reliable than a software re-creation! (Provided that sensitivity to CPU speed is solved. Geneve2020 will have several smart speed modes.)
Why not use the original flex cable? Because there are 5 new address lines to put in, plus a SGCPU bit.
Just don't plug in your physical Geneve at the same time. (What? That's a crazy idea.. too crazy.. hmm...)
Issues
Math for those following along:
an 8-bit number covers values 00-FF , which are page numbers used in MDOS
a 16-bit address covers 64K or 2^16
a 13-bit address covers 8K or 2^13 which is the single page size in MDOS
The LS612 memory mapper has at least 8 registers that store at least 8 bits.
A 16-bit address is split into upper 3 bits (bank) and 13 lower bits. The 3 bit bank# is replaced with 8 bits from the memory mapper register.
The resulting 21-bit address is the full address in 2MB space or 2^21
Adding 5 address lines to the P-box gives the 2MB address space that the physical Geneve used.
1. How does a 16-bit memory address from the 99105 translate to a 21-bit P-box 2MB space address?
Here's the problem:
The flex card interface doesn't own the memory mapper--the FPGA does.
The LS612 type memory mapper is inside the FPGA--thats how the FPGA translates 16-bit addresses together with page numbers 00-FF into 2MB Geneve addresses (or memory-mapped devices). Inside the FPGA, there is a Geneve 2MB memory map, actually located somewhere in the 32MB main memory. (there is a 2MB base address that is added for each memory cycle... it might just be 0)
So how can the FPGA tell the flex card that a) this is definitely a P-box cycle and b) here are the upper 8 bits of the address (the page number)?
1A. Half of the time it is probably in GPL mode, so the 16-bit address is actually all the P-box needs.
1B. From MDOS mode, the flex card needs that 8-bit page number!
Solutions:
1C. First, add a backplane line "External Bus Access Enable" (EXBAE) from the FPGA.
1D. This is where it hurts... 8 address bits out of the FPGA is a pretty big chunk of the pin budget (it will break the budget.) Does it have to be a direct 8 address lines?
Can it be sent serially? Any delay in transmitting this to the flex card, will ruin the memory cycle timing. I've done the math for the 4A and it barely works in a 333ns cycle; 99105 address window is 83ns. Granted, the FPGA/flex card combo is generating wait states at this point, which gain the time. Still, a LS164 shift register (serial in, 8 bit out) on the flex card would need CLK, D, RST - 3 wires. I've spent a hundred hours debugging that scheme already--using the 4A side port. An 8 bit direct line is much cleaner.
I guess 4 lines is a conceivable budget to pull this off. Though 9 would be better. I'm still not sure if more signals are needed. Does the FPGA generate the wait states and 16-to-8 multiplexing? Does the flex card do that 16-to-8 with an onboard state machine (just like the 4A). This would all be much easier if it were integrated into the FPGA, and save a lot of chips. Then the flex card would be just 244 and 245 drivers, plus 8 bit latch (bringing the data bus up to 16 bits.) The FPGA would generate A15, WE and DBIN, and wait states for the CPU. That's 12 lines for parallel... 7 lines if a serial LS164 scheme is used.
I'm going to think about this some more.
2. I also don't understand which Pbox devices might generate extra wait states.
==========Hmm, all this becomes simple if I conceive of it as an 8-bit peripheral next to the VDP... that reuses existing pins! Yeah, the flex card gets one port for address (like VDPWA), another for each data byte (like VDPWD)...
Port 0 Write 3 bytes of address, using CSW pulse. (VDPWA takes 2 bytes of address)
Port 1
Port 2 Read/Write data, even byte
Port 3 Read/Write data, odd byte
VDPWAIT - this is where the P-box READY line goes.
The additional signal, EXBAE, is a function of the flex card being selected and read/written. No additional pin required.
So... that's the flex card interface, with 0 additional FPGA pins used up. Yeah!
I've been calling this the "8-bit bus" or "slow bus" for a while now. I realize it also contains the P-Box solution.
0 extra pins required!!!
To Read before Write?
An option here is: whether the Geneve2020 emulates 9995 or 9900 read-before-write bus activity on the 8-bit bus.
Memory cycles for 9900 or 99105 16-bit data bus:
Read 16 bits. (2 reads)
Modify 8 bits
Write 16 bits. (2 writes)
Memory cycles for 9995 8-bit data bus:
Read 8 bits (if say we are doing Add Byte)
Write 8 bits
The FPGA is going to do what the 99105 tells it to do. So, there will be a read-before-write. Unlike the Geneve 9640.P-box cards for the 4A work fine with read-before-write. Are there any cards for the Geneve that don't like read-before-write? I hope I am not overlooking something...
Slow Bus Device Select
I need to finally convert the unused pin, to the SS2 select bit that I expected. The 8-bit device list is now:SS2,SS1,SS0 000. VDP1 001. VDP2 010. FM1 011. FM2 100. Flex Card memory 101. Flex Card CRU 110. Speech 111. Cartridge port
The 8-bit bus control register is thus:SS1. SS0. CSR. CSW. A1. A0. SS2. WAIT.I will rearrange this in the next VDP PCB and further peripherals (not on PCB yet), and add SS2 to the 138 decoder. (see last post for raw details of VDP access.)
The 8-bit data register is still:
D0 D1 D2 D3 D4 D5 D6 D7-
3
-
-
3 minutes ago, Lee Stewart said:Indeed. However, a few of what you listed are, in fact, in XB: PI, SQR, RPT$, DELETE, TAB.
...lee
So they are. I got mixed up with the several flavors of Visual Basic in my head. I thought TI had SQRT. I don't recall ever knowing to use TAB!
-
18 hours ago, Ksarul said:Actually, IIRC (from something I read in one of the CC40 manuals BITD), the CC40 BASIC is a subset of TI BASIC. I suspect the programs should run without the need for conversion.
CC40 has several functions and commands, some from the broader TI BASIC family, outside of Extended Basic, some CC40 specific.
The question is, does it save programs in the same format? I don't remember if I tried to OLD/SAVE across RS232 even.
If it uses the same token table, there might still be keywords XB would not know. Others like RPT$ are probably just spelled out (wild hunch.)
CC-40 Enhanced BASIC keywords that are not in TI-99/4A BASIC or Extended BASIC Mathematical Functions ACS ASN DEG GRAD INTRND LN PI - XB RAD SQR - Basic and XB String Functions KEY$ NUMERIC RPT$ - XB Memory Management ATTACH FRE RELEASE File I/O DELETE - Basic and XB FORMAT VERIFY Screen PAUSE TAB - XB Commands RENUMBER - same as RESEQUENCE CALLS ===== ADDMEM CLEANUP DEBUG EXEC GETLANG GETMEM INDIC IO POKE RELMEM SETLANG note: CALL VERSION returns 10 -
2 hours ago, InsaneMultitasker said:Does anyone have an old PEB cage/backplane that they no longer want/need?
Yes. Let me check my garage. It’s a backplane inside metal only.
-
2
-
-
For the curious, the promised FORTH source code for VDP primitives:
https://gitlab.com/FarmerPotato/geneve2020/-/blob/master/src/vdp/vdp.fs
Feel free to explore the rest of the repository. Geneve2020 will always be open source.
These words run on the J1A FORTH processor inside the FPGA. This is a very useful feature of the fpga, so that some implementation can be done in a high-level language. It is kind of cheating to have a 25 MHz coprocessor, but, it will be invisible.
In the future, these VDP words will run under the 99105 FORTH, too. The io primitives for J1A ([email protected], io!) will be coded as CRU read/write, which the fpga will translate to the J1A io registers. So VDP access from BIOS will be through CRU. But don't worry, that's only for the BIOS. MDOS or GPL still access VDP in the usual way.
The BIOS will be written in 9900 FORTH - analogous to OpenFirmware from PowerPC days. It will be in EPROM. The machine will always boot into BIOS, initialize some things, then go directly into MDOS (loaded from the CF card). Unless you push a key to get just the BIOS (FORTH) prompt.
Also, upon a system crash, aka Blue Screen of Death, or debug LOAD interrupt, you can drop to the FORTH prompt.
(On a PowerPC Mac, Cmd-Option-O-F was the magic keypress to boot into the FORTH prompt, where you configure or query various things, before booting MacOS).
So, there will be TWO hidden FORTH environments in Geneve2020. One that is the BIOS that does the boot process, and another J1A FORTH processor inside the FPGA. The one in the FPGA will do magic things, like a super debugger.-
2
-
-
Promised screenshot of a VSBW - VSBR cycle
Signals
CDATA is the data bus: 1 byte hex (the 00h means hex).
M0 and M1 are the mode bits or port select.
SS1 and SS0 are the chip selects - here set to VDP1.
Each CSW* low pulse sends a byte of data to the V9958. The CSR* pulse reads a byte of data (well it would, except bugs)
The SS with hex is all the above bits, shown as a hex byte.
Time axis
Starting around the trigger (T), you can see the VDP address on CDATA as 00h, 40h. This is >4000 or write to address 0. It happens during M0=1 and M1=0 (like VDPWA >8C02 on the 4A.)
After the address is set up, change M0=0 (think VDPWD or >8C00 on the 4A)
Then FFh is sent to the data port with a CSW* pulse.
Next, the address is set up again, this time to >0000 for a read (no >4 bit.)
Then the port goes back to M0=0 and M1=0 (Think >8800 on the 4A), and CSR* is pulsed. Which should result in the VDP output of FFh on CDATA but ... hardware bugs. Fail.
The analog signals like CSYNC are null, because I pulled off the analog board. Had to do that in order to reach more digital signals.
WAIT is all screwy. I'm not sure why. Its unfortunately at LS 5V level logic, while the FPGA input pin is 3V3. Oops.
The little spikes are just glitches in my logic analyzer wires. They do not show up when I use the analog scope probe. Though you can see the little knots on the red trace. Red is CSW* except the 10X switch got flipped so it's squshed.
-
3
-
-
Still working on V9958 board bringup: digital side. Status: I found bugs in hardware.MeCrisp Ice version of FORTH is running on the FPGA. It is great. I can add FORTH vocabulary at compile time. I plan to keep this as part of the BIOS.
I wrote the VDP initialization and read/write primitives in FORTH. I verified all the digital outputs from the FPGA.
This was painful because I didn't use the standard pin order on the PMOD ports:
The PMOD standard for the 2x4 data pin connector is: 1x4 row on top is the high nybble, 1x4 row on bottom is the low nybble.
I went left-right down the rows, so my PCB could have all the traces on the top layer, in order. The PCB is
quite beautiful that way and all 8 data port traces snake around into a '245 transceiver.I had to rewrite the Verilog to scramble and unscramble the bits. This took hours to get it right. Alas, this is the third FPGA project where I have designed myself into this mess. (In another, I wired the 4A data bus to the closest pins and unscrambled it in the FPGA.)
The pin headers interface to the 8-bit peripheral cards is this:
A0-A7 data bus to/from VDP B0 VDPWAIT from VDP B1 NC - B2 MODE0 register select B3 MODE1 register select B4 CSW* write strobe B5 CSR* read strobe B6 SS0 device select B7 SS1 device select C0-C7 OPL3 digital audio to the FPGA, BIOS TX and RXContinuing with board bring up--the memory test has failed. The 9958 is getting the right data, and CSW*. But no CSR*.
I finally discovered that I had this '138 with the address inputs wired backwards. So no CSR*.
Here's my '138 chip:
LS138 3-to-8 Decoder 0 SS1 VCC CSR Y0 illegal but harmless CSW Y1 -> CSR1* read cycle 0 G1A* Y2 -> CSW1* write cycle 0 G2A* Y3 idle state, both high SS0 G1 Y4 Y7 Y5 -> CSR2* GND Y6 -> CSW2* Mistake. G1 should be tied high. SS1 should be a low-enable and SS0 should be an address bit. This makes Y5,Y6 the CSR2,CSW2 for the second VDP chip (yep, dual screens or superimpose or F18A ....)Chip select bits from the FPGA, 8-bit peripheral bus
SS1 SS0 0 0 VDP2 0 1 VDP1 (got this wrong but ok) 1 0 OPL3-1 1 1 OPL3-2Back at the '138 decoder:
SS1 CSR CSW 0 0 0 Y0 illegal 0 0 1 Y1 read cycle 0 1 0 Y2 write cycle 0 1 1 Y3 idle
This '138 arrangement solves the lack of a chip select pin on the 9958 - the CSR and CSW signals are gated by
my SS0,SS1 chip selects.Alas, I wired the address bits backwards. You can see that the write cycle is symmetric, so, that works. But the read cycle
is broken in a way that I will just have to code around. Yuck. Until I rev the board.Another mistake is that the 5V WAIT output goes to a 3V3 input on the FPGA. Oops.
Here's a nice screenshot of a VSBW - VSBR cycle! The CSR signal never reaches the 9958 though, so the memory test fails.
<insert here>
Thus goes the VDP board bring-up. I will see if I can have Amanda solder some wire to correct the address pins, or, mangle the software to work with it...
I have CSR0, CSR1 primitives to hide this in.
<Hidden - FORTH code for interested parties>
-
4
-
-
9 hours ago, acadiel said:The thermal printer mod appears to work when printing a 40 character line from BASIC. A-Maze-ing also works!
I love this. A*Maze*Ing was my first module. I can just imagine another childhood containing these tiny printed mazes. (How about a Complex maze?)
Thanks!
-
-
On 4/17/2020 at 11:14 AM, INVISIBLE said:My BAD! My apologies. Time to link it to the repository. Thanks!
Feel free to copy LIFE_C.bin into any binary collection - just link back to this thread for the source code. Or better yet , include the gitlab link.
EverywhereEverything is there.-
2
-
-
20 minutes ago, INVISIBLE said:What no cartridge .BIN?
For Mark Wills’ ?
In my Zip file you’ll find LIFE_C.bin-
2
-
-
9 minutes ago, Monty Schmidt said:Sorry I'm late to the game answering this post (only a year late) but yes I'm still lurking around. I happen to have made my way in a circuitous route to Canada, the land of Ryte Data, and am now residing in Ottawa.
Great to see people are still enjoying the stuff I wrote 35 years ago. That's just crazy.
Monty!!!
I've googled you a few times over the years.
I remember Techie!
-Erik Olson of TI-Net BBS
-
17 minutes ago, arcadeshopper said:they have an 8 bit mode.. and for the 1meg and 2meg carts .. here's a fun one but I used flash chips on this one
Took 2 to hold the dragon's lair intro
Aha!
I learned just now that TI's 4800 8Kx2 ROM had a 4-bit mode. In case you had a 4-bit computer?
-
2
-
-
35 minutes ago, arcadeshopper said:We use these for the yellow cart board
Sent from my LM-G820 using Tapatalk
What is that? what do you do with 16 bits unless it's in the console?
-
54 minutes ago, OLD CS1 said:YOU built it... that is the key. OEMs have been historically just aweful with their AMD systems. This came to light several times regarding OS upgrades where the presence of Intel drivers caused Windows upgrades to fail. Several Microsoft Knowledge Base articles existed (might still) on the matter. I recall one such instance where it lead to computers which would not boot.
Lazy, lazy OEMs.
Maybe I got lucky. I went over to MicroCenter and talked to a sales clerk about what they had on the shelf. I got the newest Gigabyte mobo supporting AM3+ socket. I've had flaky mobos in the past, but not this one.
I think I have 16GB of Corsair RAM. I've upgraded the video card once (both ATI), moved to an SSD, and added that MemoryBoost thing on a stick.
The only complaint I have about the Gigabyte Mobo is that it still takes 3 tries to plug in a USB. Sometimes more, because of SATA plugs that look like USB.
-
3
-
-
I just learned about TI's 16-bit wide EPROMs. Here's some on eBay:
I was going to use a pair of 27C010 (128Kx8) with every other byte wasted (identical images in each, A0 hard wired to 0 or 1). That gives 64Kx16 in the end.
But this 40-pin chip is just so cute, and it saves space. (1 40-pin ZIF socket vs 2 32-pin ZIF sockets.)
And it's in the TL866-II programmer's list.
-
3
-
-
3 hours ago, InsaneMultitasker said:When I disassembled the 8K ROM image, I noticed that the DSR is only 2K. And it is pretty well crammed into that 2k window... did TI produce a 2K ROM? My thought was they created the DSR with 2K in mind but used 4K hardware?
Do you mean, did they sell 2K ROM chips? The TMS4800 is a 2Kx8 mask ROM . According to the 1975 data book, you would deliver your ROM content on punch-cards, encoded in octal digits. By 1984 the low end was the 4732 ROM. The 2516 2Kx8 EPROMs were sometime in between.
1984 https://archive.org/details/bitsavers_tidataBook984_15352413/page/n11/mode/2up
-
On 4/14/2020 at 11:39 PM, JJB said:The last year I have been working on integrating this happy trio with the TI:
I have designed a generic Arduino DSR shield for the TI, with the first application the emulation of three DS/SD floppy drives.
Have a look at github.com/jambuur/APEDSK99 for all the hardware and software details.
This looks great! I bet it could open up a whole new world of hardware hacking, for those looking for a way to get started!
-
1
-
-
38 minutes ago, arcadeshopper said:yepyep.. this is why I always check updates.. and.. never use AMD
save 40 bucks.. waste 300 hours
Maybe... I built my PC 7 years ago on an AMD FX-8350, and it has been running smoothly ever since. (still on Windows 7.) It is my engineering workstation.
MS Office, LabView, Kicad, Virtualbench, CorelDraw, Diamond Lattice, Vivado, and of course Classic99, everything I throw at it.
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
Geneve 2020 Block Diagram
Notable features of this design:
The CPU and peripherals are all plug-in cards to a backplane. Easy to repair and update. Even the CPU is a plug-in card.
There is a 16-to-8 bit bridge. This lets 16-bit cards run at full speed, while access to 8-bit devices (VDP etc) goes through a bridge, similar to the 4A.
You can have 1 or 2 VDPs. Suggested configuration is a V9958 and an F18A (mk1 or mk2.) But two V9958 is an option.
8-bit bus can support a cartridge slot, and a P-Box interface (new flex card.)
Sound includes an analog output path (mono), or digital mixing to 2 or 4 (analog output) channels. The SN76489 (original sound chip) is not included in digital, but can be emulated.
FM card includes 2 OPL3 or 2 OPN-A type chips from the 1990s. They are either simple stereo analog output, or the far more capable digital path. This gives 12-voice polyphony or 24-voice in OPL2 mode.
(I forgot to draw in the 2 SD card slots. These are on the FPGA too.)