FarmerPotato

Hi! I think there should be a Parsec sequel. I have a lot of ideas of my own for a 2D scroller intended for the F18A. But.. Also inspired by Raycaster, and on the 4A, regular bitmap mode: I have worked out the math for a "Death Star" trench run. It is much less general than Rasmus' raycaster. The view is in a trench, with texture-mapped sides and fixed stars. You see your ship and others as hardware sprites. It uses pre-calculated raycast tables for every X, Y position of your starfighter. The shifting point of view will be dramatic. I think it could fill across the middle third of the screen, in fat-pixel mode (1x4, just like Rasmus' Raycaster) and achieve an acceptable frame rate, pushing up to 2K/frame to VDP. If the frame rate is not acceptable, figure out optimizations, or make the view narrower. Ships would be regular sprites, not textures (I guess.) The 32K memory expansion is allocated as: 12.5K data, 8K texture, 2K for sprites, the rest for program. If it were a paged 64K cartridge, 32K for texture, more sprites.

FWIW, outside of MDOS mode, I won't always need to watch out for 99105 MOVB to VDP. There is another way to access it, albeit with an extra cycle (I'm not sure but I might need a wait state on VDP anyway!) The BIOS will use this method at startup. * setva from r0 SETVA LI R12,>8C02 * vdpwa SWPB R0 LDCR R0,2 * byte parallel SWPB R0 LDCR R0,2 * byte parallel RT * write a byte LI R0,>0800 BL @SETVA LI R12,>8C00 * vdpwd LDCR R1,2 * byte parallel ... * read a byte ORI R0,>4000 BL @SETVA STCR R1,2 * byte parallel It might be nice to create a 16-bit register on the video card, that did 2 8-bit writes without taking up bus cycles, but, that's overly complicated. I haven't tested this interface at all yet. I am still plugging my FPGA test board directly into the vdp card's data port and control lines.

Thanks, page 80 it is. I don't understand what you mean by WS fetch on the 99000 MOV? I see only DOP bus state in the table. The only problem left is MOVB on the 99000 in MDOS mode. Since VDPRD == VDPWD, then MOVB does a word read of VDPRD before a word write to VDPWD, messing up the address counter. That's the one I have to suppress by checking bus state. If the video card PLD could incorporate bus state, to ignore DOP fetch, allow SOP fetch. If I put this into the PLD's address decode, it is not too bad, if I have enough inputs. So I don't need the FPGA to assert BMO-- that was really invented for memory-mapped ports on the FPGA itself. It tells the bus "hey, I've got this."

I resemble this remark. https://hackaday.com/2020/10/13/the-potatoes-of-doom/

There were micturations for my 99105 chip.

Oh great gabbleblotchits. There is indeed a note on p.80 of the 99105 databook, that says MOV skips the DOP fetch. However, I still have this problem for MOVB. I worked out all the timings for 9900 and 99105 when Rasmus posed the question about optimizing non-aligned memory moves. I must check if I really used that number.

Thank you, I was not looking at the 9995 databook, was stuck on how to solve it if the 9900 and 99000 were doing MOVB, after reading a lot of their timing tables. I see now in Table 9 Instruction Execution Times. It's actually much easier to deal with! Now I get how the Geneve could have both the VDP read and write registers at the same addresses. F100 VDPWD / VDPRD F102 VDPWA / VDPSTA F104 VDPPT2 F106 VDPPT3 This is still an ugly problem I have to deal with from the 99105: MOVB R1,@VDPWD first does a DOP fetch. The FPGA, in its memory mapper section, will have to suppress the video card when it sees that address, RD/WR*=H, and bus state MEM=L, BST1-3=HLL, signifying a read from DOP, and also that SPAMM is set for that page. It responds by asserting the "BMO" or "Bus master override" when that read cycle begins. BMO makes any card's address decoder disabled. (For instance E2A* on a '138 chip is driven by BMO.) It is not a problem in GPL mode because 8800 and 8C00 are distinct. Unfortunately, that leaves the whole data bus in high impedance. I guess I also need the FPGA to drive the bus for that cycle. Cards know what mode the OS is in, sort of, because the memory mapper register has a bit SPAMM to tell that some port addresses are memory mapped. When running GPL, 8000-9ffe is SPAMM. In MDOS mode, SPAMM is on the F000-FFFe page. The PLD on the vdp card happily decodes all that, supporting both kinds of reserved addresses in the appropriate OS. (the "native" or BIOS mode doesn't use memory mapped ports, it uses CRU.)

Hey, I thought I replied here to you. Can you give me an idea what skills you could offer? Hardware, software, etc?

So I have fried my 99105. Another is on the way from China, maybe November. I designed a quick 9995 cpu card that I can wire wrap. It will require 2 wire changes on the memory card, because I anticipated 8-bit CPUs. The ROMs are lazy: they are two identical images, but one has A0=0, one A0=1 (LSBit of address). For the TMS9995, I need a jumper that attaches CRUOUT to A0. Eight data lines are just ignored. Same ROM! Static RAM has the same pattern. It turns out the video card modification is a lot messier, because the 8-bit access mode was with Z80 in mind.. and the 9995 MOVB does read-before-write, 2 8-bit bytes, all the time. Ick. But I have a minimal set of jumpers chosen so that the memory or video card can be changed from TMS99105 to TMS9995 operation. I'm going to build the TMS9995 in wire wrap while I wait.

I'm thinking about what it would take. I'm not sure the extra user pushes the memory too much higher. My abandoned code for "Hobbit", the TI-Net BBS rewrite in all assembly. It had the data structures for the user and the message board they were reading. I crammed a lot into 128 byte records. I only had the utility routines to measure footprint by; those were between 8-16K. I'm also mindful that, in another abandoned CRPG, I crammed all the monster and item data for a map location into 64 bytes, by encoding it sort of like MIDI, sort of like LISP. I did that because a 16x16 map sector could be compressed into 192 bytes with 64 left over for data (:. The 6-bit map codes stood for 32 "fixed" tileset and 32 that varied by what part of the world it was in. Each "thing" took from 1-16 bytes, where 16 bytes might be a treasure chest with 3 used items and a trap and an orc that got in there somehow. Bytes in the range 80-FF signified new items, monsters, attributes. Unrolled items don't need any further bytes. After rolling attributes, those insert bytes in 00-7f. So a new orc might be A0 xx. It's followed by 7 bits of location. If you fight it, it rolls for hit dice (80) and records its hit pts in attribute 81, so it becomes A0 xx 81 hp or 4 bytes. If it steals your ferret, that goes in its inventory (F0 starts a container, F8 marks its end). Then it has 8 bytes maybe. If it spawns with or picks up a magic sword, that might add a lot of bytes. Same if you cast a spell of slowness or haste on it... At save time, that gets prioritized and squished down, possibly destroying a magic item. A get() routine retrieves either the customized attribute or a default. Anyhow, I would do that and there would be a lot of small cache records moving around. My brain is targeting 32K. Still, for a server, requiring some SAMS is not unreasonable. The client could probably be a more basic system. 32K for sure since it's a serial connection.

It’s an interesting challenge to think about even a 2 line BBS running natively. It would involve polling two serial ports, or even four, constantly, to Asynchronously buffer input or push output. I have some experience here... Instead of a branching structure of one-user command prompt loops, with just a few interrupting sysop keys.. There would be a round-robin state check and for each user a queue of tasks like fetching a file record or sending a string or checking response. I remember the Compuserve Muds from the 80s. maybe the Pi could run a straightforward TCP server and assign session numbers to each “caller”. A back and forth protocol over Tipi would comprise packets with a session identifier and data string. I just read how Tymnet bundled chars for many users together in a packet, which was fascinating, but not needed in a short link. I don’t need another rabbit hole though. My yard is full of them.

I am starting a new thread to ask questions that come up during debugging of Geneve 2020. I appreciate any insight that anyone can give! The status at this point is that I have a backplane, with cards for CPU and some Flash ROM and RAM. However, last night I replaced the crystal with a 12MHz in order to run the memory bus at 3MHz. Then I turned it on. Nothing. Horrified, I saw I had my supply set to 6V. I changed to 5V and checked CLKOUT. Nothing. Last time I checked, it was a steady 6MHz, now I expected 3MHz. Have I fried the 99105 CPU by applying 6V? This is the ceramic TMS99105AJDL, date code 9123. By itself, the CPU card is consuming 350mA, as it did before. The memory card adds 350 mA. No CLKOUT, 0V on XTAL1, 5V on XTAL2. I desoldered the crystal and put the 24MHz back in. For a while I got this clock. Then it flatlined and now it consumes 700-900mA. Generally the outputs show a flat 3.6V. Ideas? Vertical scale is 5V. So bad undershoot. From 4V down to about -2V before reaching 0. The signal is driving one input of a '645.

I have learned a lot about how difficult the routing can be, from trying out a lot of ideas. I started with a simple 4A side port module, unscrambling the address and data lines, then a 512K cart. I've tried a lot of schemes for routing data and address lines vertical or horizontal. There is always a really hard problem when a few signals have to go all the way across the board. PLCCs are great for saving space but the pin layout kills me. And invariably I have to start from scratch three times, because a corridor between chips no longer permits any more traces, there is an impassable wall, or VCC or ground is cut off (I use top and bottom plane fills for those.) Or I underestimate the caps and such, putting them in too late. (I use big 1206 or 0803.) Or the board space is just too tight. Or my technician says "I can't solder this" on final inspection, before it goes to fab. This board is probably unroutable. I put some effort into that before I gave up on this form factor. The 3.3V FPGA was sort of central terminal, with all the CPU lines buffered into it, and "fast" memory bus and "slow 8-bit bus" going in and out. I just updated the BOM from where I left off. The ICs cost $183. The costliest parts, which I've sourced in Qty 10, were: $30 TMS99105ADJL $30 DRAM 32MB (you can use just 2MB for $10) $20 V9958 x 2 $17 SRAM 2MB $10 TMS9901 x 2 $8 TMS4464s x 8 $8 ICE40HX-4K FPGA $6 TMS9902 x 3 $5 LT1675 RGB Switch (superimposer) $4 TMS9995 The modern ICs in the list are the SRAM, the FPGA and the video switch. I hate to think how much money I would pay for multiple spins of this big PCB! All along, I've put cost-efficiency near the top of my list. All Geneve2020 modules right now are made on 10x10cm plug-in cards, which you can get dirt cheap (yeah, dirtypcbs as low as $2). My 160x100mm motherboard cost $20 in a group buy (it's a standard retrobrewcomputing bus.) Eventually the 100x100 modules must coalesce into 100x160 boards. At this point I budget $350 BOM for the final product. I listen to what is top of folks' priority for wanting a new computer. MDOS compatibility. SD cards. Works in a PC case (in addition to my cool enclosure). Support for legacy PBox (future 3rd party option.) I'm going for standalone GPL with superior compatibility. Almost everything else is whatever I think fits my design goals and pet ideas (yeah some of those have to be killed.) So that maximizes my fun. I don't yet know how to bring in other people. I want to work with TheBF on the FORTH BIOS. I want pnr's Macrostore disassembly so that any 99105 can work. I need serious help with the analog VGA I've put together (I get a textbook 15khz signal out, but I don't get anything to sync.) And I have never done a DRAM refresh (that will be Verilog) As a learner, my Verilog has gone from "it sucks", to "it finally works!" Recently it's more like "hey I followed the textbook, made a Mealy-Moore machine by the book, and it works great in simulation. Now about those glitches." I read in Matthew's interview with EETimes that I needed to get the Pong book. Best advice so far!

I've copied your message to the people in the copy department.

More than a year ago, I made an template of a console PCB in KiCad. Then I stuffed in all the components I could imagine for a new Geneve. The idea was it would re-use a 4A console case. Some wacky ideas that went in: In addition to the 99105 computer, a separate 9995 co-processor for keyboards, mouse, joysticks, Hexbus. Two VDPs. A cartridge and a TIPI slot. SD cards accessed through the console side door! It was a fun idea to begin with, but I got frustrated with fitting parts into the console space. It was too crowded to go forward (or route all the traces.) While I was excited about replacing the console motherboard for the "stealth" look, I don't think anyone else was a fan. I moved on, to a set of smaller modules. That has evolved into a 16-bit Eurocard backplane. So it's nothing like modding the console anymore. Here are some pictures from that:

That's wonderful! I like the construction, to protect both sides of the PCB. Only last month I learned it was called a "Standoff Sandwich" or "Clock Cage".

I mean, copy-posting your info on a new thread.

How about starting a new thread for Kienzle on the subforum? https://atariage.com/forums/forum/345-tomy-tutor-cc40-992-998-cortex-990-mini/

eBay suggested a Seiko/Epson 72423. It looks similar: 16 registers, BCD, but the registers are in different addresses. No tenths of seconds. Not quite compatible. These are still stocked by Mouser, for $8, but old ones are out there. Modern Seiko-Epson RTCs are all I2C or SPI with the exception of: RTC7301DG. The RTC7301SF comes with a temperature sensor! Still around $7. https://www5.epsondevice.com/en/products/rtc/rtc7301sf.html Registers match 72423, ie offset from where MDOS looks. Not cheap either. Except 72421 used.

The 58274? did you have a good source?

Hey, here is a copy of an Application Note for the 58274 under a friendly document name! https://cdn.preterhuman.net/texts/computing/msx/Geneve_Clock_App_Notes_AN-365.pdf There's a nice personal collection of documents there. Probably all in wht already but... Holy crap, it's a mixture of TI-99/4A documents and MSX, including service manuals for the CX5M. I am having a feast... Thanks, clock chip!

Octopart shows a bunch of those but mostly for $6-$12, except one Harris brand copy is at Rochester for $0.86 Hmm, SPI is sorta ok. It means I have to memory-map it through the FPGA. Maybe have the FPGA shadow it continuously every 0.05s. But with that technique, I could use any $1 SPI chip and make it look compatible. MC68HC68T1 is another that is similarly costly. I might go for some legit-looking eBay 58274 chips and test them. Thanks for locating that alternative!

I'm looking for a source of clock chip MM58274. It was used in the Geneve 9640. It has 4-bit registers, mapped with 4 address bits. Here is the thread I found with some history: I looked for MM58274 on aliexpress, and it goes for $7. I looked at several sellers that use the same photo and price. $7 I found this for $1 that is possibly fake. It doesn't have the Microchip logo, but has a sane date code. It could be a remark (laser on new markings because old ones are faded), a fake remark (dummy chip, usually with impossible date code), or else Microchip used another fab in '95. $1 for real? Mine in the Geneve 9640 has the logo and '87 date code. Any opinions on whether that is real or fake? I can try one sample for $6 shipped, might be worth a try. eBay is a mixed bag but there are a lot of photos there. One from '99 has the Microchip logo. Or another source?

I looked and found two articles on Kienzle 99000. They indicate their 9000 systems were sold til at least 1987 when the company planned to make Unix workstations. In 1991 it was sold to DEC. https://www.google.com/amp/s/www.cbronline.com/news/kienzle_takes_its_9000_into_the_factory_as_it_waits_for_competitive_unix_box/amp/ https://www.google.com/amp/s/www.cbronline.com/news/mannesmann_kienzle_reassures_customers_of_its_commitment_to_unix/amp/

That's a nice color. Here are the specs from 2004 https://www.necdisplay.com/documents/colorbrochures/lcd60_series_0204.pdf It starts at 31.5 kHz dot clock, so it is not the "multisync" of the 90s. It wouldn't cover the 15.75 kHz required for V9938 RGB for instance. F18A does 31.5 kHz which is common. HOWEVER, neither do the 70 models,according to this brochure from 2008: https://www.necdisplay.com/documents/colorbrochures/70 series brochure_0608.pdf AND YET, there are reports that several 70 series such as the LCD1970NXp work great with 15.75 kHz. See this list here: http://15khz.wikidot.com/ A 50 series is reported NOT to work. Two 90 series are reported as full support. I don't want to spend $100 to find out. though like Omega said it would look nice on my 4A with F18A.