Jump to content
FarmerPotato

What if? Designing "Geneve 2020". Cool 3D views!

Recommended Posts

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. 

Share this post


Link to post
Share on other sites
40 minutes ago, wierd_w said:

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:

image.png.e25ad78518e6c6f96c2a9b7f070d5621.png

 

So im done with this for now and proceeding with the LabVIEW version.

  • Like 1

Share this post


Link to post
Share on other sites


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.

  • Sad 1

Share this post


Link to post
Share on other sites
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?

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.)

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by pnr

Share this post


Link to post
Share on other sites

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."


 

 

Share this post


Link to post
Share on other sites

 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.

 

 

Share this post


Link to post
Share on other sites

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 :D

Share this post


Link to post
Share on other sites
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 :D

Thanks. But I'm trying to avoid 3D printing. Its much faster to obtain plastics by laser cutting.

Share this post


Link to post
Share on other sites

 

IMG-1375.thumb.JPG.a88d288fb7fb5d559a3c2d6ff722364d.JPG

 

 


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

 

  • Like 8
  • Thanks 1

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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.

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites

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

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...