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

[+FarmerPotato]

1 hour ago, InsaneMultitasker said:

 

YES!  That's the flying thing that keeps landing on my desk!  How do I make it stop buzzing?

 

Oh look, we're on page 20 of 20 now.

 

 

[+FarmerPotato]

Now that the data pin is cleared up.

LI   R12,>1380   

It reads >1380 from ROM and writes >1380 into R12 at RAM >8018.

 

SBZ  31

 

It reads from R12.  The data bus goes wobbly.  It shows 0380 .. 0080 .. 8080 .. 0080 .. 8080 and that is what is sampled. 

That results in a write to CRU >80BE.

 

So no RECOGNIZ tonight.

 

The bits that were lost are AD12,AD9,AD8 (>13).  They are all very weak on the scope. It seems to just be the MSB. Something somewhere may be contending just the MSB of the bus, and it's sucking all the current out of the RAM driver.

 

Pathetic "1" bit

First pulse is ROM driving the pin.

Second is CPU writing to RAM.

Third is RAM emitting the 1.  It looks so sad.

 

A7 is fine. (The label wrongly says AD9) First pulse is CPU writing to RAM, second pulse is RAM emitting the 1.

 

 

[+FarmerPotato]

No closer to solving the bus contention or weak drive from RAM. There are a lot of drivers waiting on the bus, with their own OE disabled. I can't find the fan out number for the IS61..256x16 RAM. Maybe reflowing the pins will help. 

 

 

I replaced the PLCC with damaged pin. Also redoing the wire to pin 2 whose pad I ripped up very early.

 

Curious thing up above. When SBO 31 reads R12 = >8080 its result is...  undefined.  The address emitted in the BST=B cycle /IO) is A0Bx something. The data is the usual undefined value 801F. 

 

If I get tired of the RAM problem I'll just change the CRU address to 1280 and play with that  

 

Exciting news for me: Digilent will support my NI VirtualBench 8012 scope.  NI last supported VB-8012 in 2019;  a promised update never got past Beta. Digilent sells VB as Analog Discovery Pro, but with their own software Waveforms.  As of September 2023,  Waveforms supports the old VB-8012.

 

One new feature I'll get from Waveforms is the Impedance vs frequency chart.  Thinking of how to take advantage of that. 

 

[+FarmerPotato]

Theory: I'm suspecting that the 3 problem RAM data pins are poorly soldered or loose. 
 

If there were contention on the bus, it should manifest in other ways. If the RAM had pins shorted together, it should create problems everywhere. 
 

I might move on to building the second board copy, with lessons learned. The damage to #1 is a problem. Difficulty re-applying the wire fix for destroyed pad ROMEN on ROM U23. tested it's not shorted to its neighbors, but I may have broken another trace. 

 

[RickyDean]

Can anyone that knows what is going on, tell me if this paragraph on the github site for the Tang could be an issue for the Geneve ?

"V9958 128KB VRAM: Tang Nano 20K

The v3 of the fpga code and mainboard is for use on a Tang Nano 20K only. There are no other versions for Tang Nano 20K other than V9958 128K. If you need a 9918 use the Tang Nano 9K instead. The socket for the TMS9118 is the same from v2. A socket for a V9958 replacement is in the works.

See instructions below for programming it.

Note The gromclk signal has been retired from V9958 128K (no MSX ever uses it). So instead turning this jumper on puts the VDP in no-wait mode, full speed 27Mhz. Turning off it makes the VDP at normal speed (for VDP commands)."

 

Does the Geneve or for that matter the TIM for the Ti99, use the gromclk signal? I'm downloading the source for Mame and going to compare code for the 9938/58 with the code for the Tang

 

[+9640News]

I don't know if this matters, but VR#8 (9938) has a setting for type of VRAM.  I don't know if this is an issue for you or not.

 

Is there any hint whether MDOS booted such as typing DIR DSK1. after the Geneve has booted to see if you have made it to the CLI?

 

Source code for the V2 eprom which is based upon the early eproms can be found on Github if you go to www.9640News.com and look at the github repository links.

 

[RickyDean]

2 hours ago, 9640News said:

I don't know if this matters, but VR#8 (9938) has a setting for type of VRAM.  I don't know if this is an issue for you or not.

 

Is there any hint whether MDOS booted such as typing DIR DSK1. after the Geneve has booted to see if you have made it to the CLI?

 

Source code for the V2 eprom which is based upon the early eproms can be found on Github if you go to www.9640News.com and look at the github repository links.

 

Not at this moment, but the reason is probably this. I have an AT power supply in the PEB and the Geneve and the HFDC both have recently had their jumpered regulators replaced with DC/DC converters, so the Geneve will still show a screen with the power getting thru, but the HFDC doesn't activate to try to boot. I just experimented today, but have been in and out of sleep mode from the surgery healing. Tomorrow I'll be trying to place the two into a regular PEB and see if the Geneve boots from a floppy.

[RickyDean]

Well, I just moved my Genny into the Den and pulled my TI stuff out of the box. I then proceeded to hookup the Tang unit and a USB-C cord to power it as it does not power from the HDMI or the V9938 socket. I then hooked up my HFDC and placed the boot disk HFE into my  HXC floppy emulator and powered up. I get a corrupted screen where the Swan should be. But after some seconds the floppy drive is activated then it activates it again and after some moments I get the Enter Time screen for Geneve OS. I don't have a keyboard hooked up, so cannot go further at the moment. Did take a video, but it's 181MB in size so can't upload it. But the main thing is, it works.

 

Just uploaded the video to youtube, here is the link  

Also moving this back to my Tang thread.

Edited December 6, 2023 by RickyDean
additional content

[RickyDean]

16 hours ago, 9640News said:

I don't know if this matters, but VR#8 (9938) has a setting for type of VRAM.  I don't know if this is an issue for you or not.

 

Is there any hint whether MDOS booted such as typing DIR DSK1. after the Geneve has booted to see if you have made it to the CLI?

 

Source code for the V2 eprom which is based upon the early eproms can be found on Github if you go to www.9640News.com and look at the github repository links.

 

If you look here you'll see that last night I did go into MDOS 6.5 successfully and pulled a pulled up a directory of dsk1. Moved this discussion back to that thread.

 

 

 

[+FarmerPotato]

16 hours ago, RickyDean said:

I just connected a keyboard and was able to enter the time and went into MDOS 6.5. Then I pulled up a directory of the drive. Crystal clear, on HDMI.

 

Yay! Copying it this thread.
 

This will make another option for Geneve 2020. 
 

My designs for video card currently include:

Easiest: hosted F18A (16K)

Middle: V9958 RGB out. Got this mostly. 
Other: V9958 socket with no analog  
Hard: V9958 with built in VGA/SVGA converter. 

[+FarmerPotato]

No real progress in days.

 

I had replaced the even ROM socket, U22. Its ROMEN bodge-wired to odd ROMEN, U23. (Lifted U22 ROMEN pad/trace due to soldering at 570 F.)

What I see now is ROMEN pulled low to read 0000, but wobbly 1-2V when reading 0002. Bus has:

 

Cycle    Addr   Data   Comment
RSET     801E   801E   acknowledges reset
INTA  R  0000   8000   correct data.. but is it coincidence? high bit AD15 likes to float high.
WS    W  8018   xxxx   address of R12. Should be 801A for R13. 
WS    W  801C   xxxx   should be 801C
WS    W  801C   xxxx   should be 801E
INTA  R  0002   0002   should be 0054. data bus probably hi-z. Might be 573 latch or CPU holding last inputs.
IAQ   R  0002   0002   shows that PC got 0002
AUMS     xxxx          locks up in infinite loop

 
 

ROMEN and L_A1 are wobbly when they should be 0 and 1.  Looks like a short from ROMEN to L_A1. Their traces  travel together next to the destroyed pad of ROMEN. 

 

I guess I could remove the socket again and wire ROMEN up and over.

 

And, spend equal time building on PCB #2 with lessons learned. PCB #1 may be toast. 
 

Three of the RAM data pins go wobbly in a similar way. I see a pattern that corresponds to the address being read.  Possibly the same kind of short, but on L_A8. The most likely place for these traces to short is where the toaster oven landslide wrecked the '573. 
 

 

 

 

Edited December 7, 2023 by FarmerPotato

[RickyDean]

In the MDOS 6.50 disk image I used, I tried to run CYA and got a graphics mess, unknown if it uses an unsupported mode, but I could use ctrl, alt, del and reboot, usually getting a slightly corrupted but readable text on screen.  I ran another program Crack128 and Raveform after reboot and they both ran fine after a reboot and were readable. So it does have some issues that will need to be addressed. Also I want to see if the programming can be changed to use provide 192k memory, instead of the 128k it's currently programmed to provide. I believe the Tang 20k should be able to provide this. Also would like to see if the bluetooth and sd card capabilities on the Tang can be leveraged somehow, as well as the serial port, but more interested in it working as a replacement for the 9938/58 vdp's.

Edited December 6, 2023 by RickyDean
additional content

[+9640News]

You might want to try GPL mode with some games to see what happens with the graphics for things closer to the 9918 model and see what happens.

 

As far as bluetooth and sd card capabilities, DSR's would need to be written as a first step.  That is what happened with the TIPI.  The TIPI was probably the simplest storage device DSR to be written as most of the heavy lifting is done on the PI.  Just sending messages back and forth to communicate with the back end on the PI that Matt had written reduced the challenges.  

[+FarmerPotato]

19 hours ago, RickyDean said:

In the MDOS 6.50 disk image I used, I tried to run CYA and got a graphics mess, unknown if it uses an unsupported mode, but I could use ctrl, alt, del and reboot, usually getting a slightly corrupted but readable text on screen.

Could you describe "mess" or photo the "unreadable".  Are there corrupted char defs in the text? Like every other byte corrupted.  I wonder how they chose to emulate the DRAM, or used some cheats. Especially G6 mode has a memory quirk, that I hope nobody relies on. 

 

[RickyDean]

I will take some photos soon, I've changed out the tang for a normal 9938 to see how they work with the disk image I'm using. I had to sit here awhile to figure out the vanilla configuration for a Geneve emulated on Mame to match what I currently have in my PEB. So far I'm able to go into CYA on the real Iron, but am experiencing graphics issues when I go to the next screen and the menu comes up. So I believe this processor has issues to.

[+InsaneMultitasker]

2 hours ago, FarmerPotato said:

.  I wonder how they chose to emulate the DRAM, or used some cheats. Especially G6 mode has a memory quirk, that I hope nobody relies on.

CYA and other 80 column programs written for the 9938 often stuff the character set and/or attribute table into VRAM bank 1.  So you might be on to something; maybe banking is a bit quirky with how they emulate the dram / vram pages. 

[+FarmerPotato]

1 hour ago, InsaneMultitasker said:

CYA and other 80 column programs written for the 9938 often stuff the character set and/or attribute table into VRAM bank 1.  So you might be on to something; maybe banking is a bit quirky with how they emulate the dram / vram pages. 

If it were switching to G6, writing the chars, then switching to Text mode. 

This is theory: I've never tried it, only read it in the manual:

Most modes address Bank 0 as 0000-FFFF and Bank 1 following. But  9938 needs more memory bandwidth in G6, so the even addresses go to Bank 0, the odds to Bank 1.  It can get two bytes with one address setup. I think of this as "interleaved columns". 
 

Outside of G6 it goes back to linear addressing. So flipping between G6 and others will make VRAM unrecognizable. Data must be loaded *after* changing to/from G6. 

[+dhe]

Wow FPo, I'd never heard that before. Good Info.

Thanks!

[+FarmerPotato]

18 hours ago, dhe said:

Wow FPo, I'd never heard that before. Good Info.

Thanks!

Now I can't find where I read that. Maybe on MSX forum their  revised V9938 book. 

[+FarmerPotato]

On 12/6/2023 at 2:51 PM, FarmerPotato said:

ROMEN and L_A1 are wobbly when they should be 0 and 1.  Looks like a short from ROMEN to L_A1. Their traces  travel together next to the destroyed pad of ROMEN. 

 

I guess I could remove the socket again and wir

Confirmed: the trace L_A1 has no solder mask where it  goes between socket pins ROMEN and L_A11 (latched address). I find a short between its exposed trace copper and the source of ROMEN. 

But how? The original pad and about 3 mm of the trace for ROMEN is gone. The rest is not damaged. I thought I would find some bridge between exposed copper and a socket pin.  Final option is to remove BOTH sockets, again, and inspect. 

[+FarmerPotato]

Here's that darn short. Under the "good" ROM where I attached the bodge wire for ROMEN.

Upper left corner, lifted trace L_A1 traveled  between pad ROMEN. 

(board is rotated 180, so is the layout below it)

Edited December 9, 2023 by FarmerPotato
images below

[+FarmerPotato]

 

 

Lifted copper trace L_A1 (highlighted) and pad L_A11 in southeast corner of  ROM U23 (odd).  The middle chip in the layout. 

 

I threaded a bodge wire from ROMEN, out and under the socket, then soldered the end to the ROMEN pad. Removed the socket again, and found bare wire that was touching the exposed trace.

 

 

This socket has been attached/removed several times, and the bodge wire re-attached.  I bet the board took too much heat and scratching, with all the manual soldering I did. 

 

 

At this point, I can

 

1. Start fresh with PCB #2, many lessons learned. 

2. Repair the trace/pad

3. Rip out the trace and poke bodge wire into some vias.

 

 

 

 

[+FarmerPotato]

For anyone wondering--I plan to have Aisler assemble the final boards for me.   Estimates when they source all the surface mount parts too:

 

PCB, SMT Parts and Assembly, Each

 

Qty

1     147 Euros

5      70

10    62

 

Acceptable.   There are still $100+ in parts that are not SMT, and many other costs.  Video+Sound board will probably add an equal amount. 

 

[RickyDean]

31 minutes ago, FarmerPotato said:

 

 

Lifted copper trace L_A1 (highlighted) and pad L_A11 in southeast corner of  ROM U23 (odd).  The middle chip in the layout. 

 

I threaded a bodge wire from ROMEN, out and under the socket, then soldered the end to the ROMEN pad. Removed the socket again, and found bare wire that was touching the exposed trace.

 

 

This socket has been attached/removed several times, and the bodge wire re-attached.  I bet the board took too much heat and scratching, with all the manual soldering I did. 

 

 

At this point, I can

 

1. Start fresh with PCB #2, many lessons learned. 

2. Repair the trace/pad

3. Rip out the trace and poke bodge wire into some vias.

 

 

 

 

Repair and go on, your learning as you go.

[+FarmerPotato]

I have built PCB#2.  Crystal works fine.  No traces damaged!   PCB#1 had too many mistakes and fixes.

 

I seem to have a problem with AD15. Then data bus in general.

 

Addr Data Expected
0000 0000 8000   problem with AD15 (msb)
0002 0096 0096
0096 1418 0300  LIMI 0, got JHE
0098 04ca 0000  
...

 

Checked ROMEN, RAMEN, RD, WE, all the latched address pins at the CPU and the ROM.  Data bus just seems random after those first two reads. 

Found a wiggly pin (not enough solder paste) at L_A2 but that was an easy fix. (L_A2 is latched A2) (0 is lsb, 15 is msb)

 

MEM and BST1-3 are fine.  PLD decodes the ROMEN signal as appropriate.  RAMEN stays unasserted because WP=0000 is ROM. ugh.

 

I didn't put in the bus driver chips, unlike the 1st build where the external data bus transceivers were left floating until I tied OE, DIR high. 

 

One weird thing: latched address bits L_A[15:1] out of the 573s. When RD* asserts, lines like L_A2 drop from 4V to 2.55V.  I put in AS573 to use them up. 

 

R_W*       1     1     1     1
MEM,BST1:3 3     3     3     3    IAQ
ALATCH     1     0     0     0
L_A[15:0]  0096  0096  0096  0096
ROMEN*     0      0     0     0

RD*        1      1     0     1
AD[15:0]   0096   1418  1418  1418

L_A2 (V)   4      4      2.55  4

acceptable, >2.4

 

At the ROMs, 39SF010,

OE* = RD*

CE* = ROMEN*