+FarmerPotato Posted August 29, 2020 Author Share Posted August 29, 2020 2 minutes ago, wierd_w said: If the issue is "File handler already in use" type errors, perhaps consider either softlinked or hardlinked files, presented in different folders? (Logically, appears as 2 different files. Really, is the same file, with two NTFS indexes.) That way the programs each think they are running independent instances from separate folders, but really the data files are the same ones. I don't think that will help. WinCUPL run an external programs which try to delete and re-write its output files. If it gets a mysterious error, it cannot get out of that state. Simultaneously, WinSIM expects to run the same stuff. It's full of synchronization bugs. I'm looking for some backward-compatibility option in Windows 7. Quote Link to comment Share on other sites More sharing options...
wierd_w Posted August 29, 2020 Share Posted August 29, 2020 (edited) Compatibility toolkit? https://application-compatibility-toolkit.software.informer.com/5.6/ It's basically the "Compatibility mode" in win7 and up, on steroids. https://docs.microsoft.com/en-us/windows/deployment/planning/act-technical-reference https://support.microsoft.com/en-us/help/317510/how-to-use-the-compatibility-administrator-utility-in-windows Edited August 29, 2020 by wierd_w Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 29, 2020 Author Share Posted August 29, 2020 40 minutes ago, wierd_w said: Compatibility toolkit? https://application-compatibility-toolkit.software.informer.com/5.6/ It's basically the "Compatibility mode" in win7 and up, on steroids. https://docs.microsoft.com/en-us/windows/deployment/planning/act-technical-reference https://support.microsoft.com/en-us/help/317510/how-to-use-the-compatibility-administrator-utility-in-windows I couldn't tell if that was current - so I used the built-in wizard. It has solved one problem! WinCUPL no longer borks when there are 2 files involved being edited in WinSIM. WinCUPL errors nicely and I can try again after I save changes in WinSIM. However this is an endless loop: So im done with this for now and proceeding with the LabVIEW version. 1 Quote Link to comment Share on other sites More sharing options...
wierd_w Posted August 29, 2020 Share Posted August 29, 2020 Glad it helped some-- It is not a magic bullet. (and it has a LOT of knobs) 2 Quote Link to comment Share on other sites More sharing options...
SteveE617 Posted September 26, 2020 Share Posted September 26, 2020 Holy cow! I had no idea this was going on. I’ve been tossing around an idea like this for years. I’d love to get involved with this project. 4 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 13, 2020 Author Share Posted October 13, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 13, 2020 Author Share Posted October 13, 2020 On 9/26/2020 at 7:49 AM, SteveE617 said: Holy cow! I had no idea this was going on. I’ve been tossing around an idea like this for years. I’d love to get involved with this project. Hey, I thought I replied here to you. Can you give me an idea what skills you could offer? Hardware, software, etc? 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 13, 2020 Share Posted October 13, 2020 44 minutes ago, FarmerPotato said: 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 always does read-before-write, 2 8-bit bytes, all the time. Ick. The 9995 does not have a read-before-write, as its data bus has only 8 lines. And it only transfers single bytes with a byte instruction. Do you mean the 9900? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 13, 2020 Author Share Posted October 13, 2020 35 minutes ago, mizapf said: The 9995 does not have a read-before-write, as its data bus has only 8 lines. And it only transfers single bytes with a byte instruction. Do you mean the 9900? 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.) Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 13, 2020 Share Posted October 13, 2020 The lack of RBW is what boosts the Geneve speed considerably, although it only has 8 data bus lines. By the way, the TMS9980A also has only 8 data bus lines, but its microprograms are the same as the ones in the TMS9900. Hence, it does RBW. The 9995 seems to be a thorough redesign. I had a look at the TMS99000; it seems to do RBW again. But there are some optimizations; the MOV instruction does not fetch the destination operand. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 13, 2020 Author Share Posted October 13, 2020 20 hours ago, mizapf said: The lack of RBW is what boosts the Geneve speed considerably, although it only has 8 data bus lines. By the way, the TMS9980A also has only 8 data bus lines, but its microprograms are the same as the ones in the TMS9900. Hence, it does RBW. The 9995 seems to be a thorough redesign. I had a look at the TMS99000; it seems to do RBW again. But there are some optimizations; the MOV instruction does not fetch the destination operand. 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. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 13, 2020 Share Posted October 13, 2020 "Gabbleblotchits" ? 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 13, 2020 Author Share Posted October 13, 2020 6 minutes ago, TheBF said: "Gabbleblotchits" ? There were micturations for my 99105 chip. 1 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 13, 2020 Share Posted October 13, 2020 17 minutes ago, FarmerPotato said: There were micturations for my 99105 chip. Poetic justice? 1 1 Quote Link to comment Share on other sites More sharing options...
pnr Posted October 14, 2020 Share Posted October 14, 2020 (edited) 19 hours ago, FarmerPotato said: Oh great gabbleblotchits. There is indeed a note on p.90 that says MOV skips the DOP fetch. However, I still have this problem for MOVB. For future readers: I think you mean page 80. When developing the Verilog model for the 99000 I came across this optimisation of MOV. It is not only the DOP fetch, but also the destination WS fetch that is skipped. When debugging the FPGA version of the TI99/2 I disabled this optimisation for a while. Much to my surprise the TI99/2 ran some 10% slower without the optimisation. There is some interesting analysis by Karl Guttag (the 9995 and 99000 chip designer) here (note that the code name for the 99000 was "Alpha"): https://hansotten.file-hunter.com/uploads/files/99000 (Alpha) Misc Documents.pdf It says that MOV is 25% of instructions, together with MOVB even 30%. Throw JMP in the mix and it is 50%. Do you still have the problem for MOVB? On the 9995 interim solution it is not an issue and on the 99105 you can ignore the read-before-write using the BST outputs, as you already described above. What other current scenario is still problematic? Edited October 14, 2020 by pnr Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 14, 2020 Author Share Posted October 14, 2020 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." Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 14, 2020 Author Share Posted October 14, 2020 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. Quote Link to comment Share on other sites More sharing options...
Tornadoboy Posted October 16, 2020 Share Posted October 16, 2020 I'm no genius at it but if you need anything for this designed for 3D printing I might be able to help. Other than that I have nothing to give but blood, sweat and tears Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2020 Author Share Posted October 23, 2020 On 10/15/2020 at 7:49 PM, Tornadoboy said: I'm no genius at it but if you need anything for this designed for 3D printing I might be able to help. Other than that I have nothing to give but blood, sweat and tears Thanks. But I'm trying to avoid 3D printing. Its much faster to obtain plastics by laser cutting. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2020 Author Share Posted October 23, 2020 This is the Geneve 2020 prototype I've been working on. Pictured here are the cards for CPU (white) and I/O (black). They are still in the board bring-up stage. The features you can see here are: 8-slot backplane. CPU and I/O cards. Card panel RESET and NMI buttons. I/O connector for FTDI (serial to USB cable) and/or PMOD accessory. Steel Hammond case Tough acetal plastic (laser-cut) The backplane is Kontron, compatible with retrobrewcomputing.com cards. The chassis can be used for Eurocard full 160x100 or half size 80x100. Front panel, (top to bottom) : Lighted power switch (you can choose any E-switch type) VGA, Serial ports. Slots for Micro-SD reader, Two MMC slots (or use Micro-SD adaptors). Two joystick connectors. Connector for 4A keyboard. Holes for AC97 phono jacks, PS/2 keyboard+mouse jacks, MIDI In/Out. All cards may have connectors and LEDs on their front. A back panel is possible, for VGA/serial etc. I put a big emphasis on keeping costs down. All the materials for the physical case and backplane are off the shelf. They cost about $120, plus $35 for the Pico power supply. The biggest items are the steel Hammond case ($50), Backplane ($40 with 8 slots). Parts assemble by snap-fit or screws. You will be able to put the backplane in a PC case+power supply, saving $85. A minimal system could also use a 4-slot backplane. After the debugging stage, cards will be combined onto 160x100mm Eurocard full size. I'm really happy with how it turned out. -Erik 8 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 23, 2020 Share Posted October 23, 2020 Tell me when you need a Forth Monitor for this beast and I will make it for you. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2020 Author Share Posted October 23, 2020 31 minutes ago, TheBF said: Tell me when you need a Forth Monitor for this beast and I will make it for you. Yes, definitely! I am testing a very short program so far * * first test * biows 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 li r12,lights sbz 0 led loop limi 2 limi 0 * 128 nops. look for instruction >1000 nop nop * ... b @loop int li r12,lights sbo 1 led rtwp end Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 23, 2020 Share Posted October 23, 2020 So it boots from a vector at >0000 ? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2020 Author Share Posted October 23, 2020 42 minutes ago, TheBF said: So it boots from a vector at >0000 ? Yes, just like 9900, RESET pin. There is a slow pull-up just like the 9904 in the TI-99/4A, except it goes through the 9904, which is cleaner. The debugger console is a 9902 at cru >1380 (in other words RS232/2) . I can only use serial I/O for the time being--VDP and PS/2 keyboard support is a long way off. I need to interactively write it! Thats why FORTH is so great! Serial code should be identical to any other 4A serial code, but probably best not to turn on any interrupts. 9902 Clock input frequency is the same 3 MHz as the 4A, so same register values. An LED is anywhere in the >1300 block . SBO on, SBZ off. So 4A style SBO 7 will work. There is no DSR to enable. LI R12,>1300 SBO 0 * on SBO 7 * works too SBZ 0 * off VDP is not ready yet. There will be a way to map the VDP into >8800, >8C00 like GPL mode. Or >F100 like MDOS mode. There is also a weird new way to get to VDP: * Set VR#7 to screen color white-on-blue, using CRU byte-parallel LI R12,>8C02 LI R0,>F407 LDCR R0,2 * a lot like MOVB R0,@>8C02 SWPB R0 LDCR R0,2 The CRU parallel address is intentionally the same as the memory-mapped port, because then the same address decoding gets reused! All the VDP-by-CRU routines are demonstrated in this src file: https://gitlab.com/FarmerPotato/geneve2020/-/blob/master/src/bios/stdlib.a99 The "Editor/Assembler" manual is here: https://gitlab.com/FarmerPotato/geneve2020/-/wikis/X.-Appendix-Reference-Tables All Wiki, home page: https://gitlab.com/FarmerPotato/geneve2020/-/wikis/home Repo here https://gitlab.com/FarmerPotato/geneve2020/-/tree/master Send me a gitlab username, and I'll give you write access. 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2020 Author Share Posted October 23, 2020 I should have asked, do you know git? The tools I use are: Cygwin, a unix-like shell on Windows. Use the installer to choose git tools. Make - again, install with cygwin Ralph's xdt99 to assemble. Requires python, so install that There is an example in the bios directory, tiny.a99 cd bios make 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.