Page 4 of 4

Re: Novatron

Posted: 19 Sep 2022, 00:07
by alastair
Thanks for the new ROM Leo. The original card is showing three lines after the boot message. The first is all white pixels and the next two are all red. I picked up a new SD card and get three all white lines. This was the case with the card in its original FAT32 formatted state and after loaded the SD card image via dd.

Original card:
card1.png (299.08 KiB) Viewed 105 times
New card:
card2.png (281.57 KiB) Viewed 105 times
I wonder if this is an issue with my hardware? It could be a timing issue or something with the logic levels. I'll have to dig in a bit deeper to understand the code and how to debug things.

I was busy the last couple of weeks with a trip to VCF Midwest. I did some demos of the Novasaur and Novatron. The picture below shows a text madelbrot generated by MS BASIC and Super Star Trek on a serial terminal. The Novatron was using the @denjhang dev/game ROM so the kids had some games to play :D
IMG_20220911_132917.jpg (1.54 MiB) Viewed 105 times
All the "famous" YouTubers were there and I got an 8 second clip in the latest 8-bit Guy video (don't blink else you'll miss it!) -

There's also a more in depth interview from Dr. Dave's Diversions available here -

Re: Novatron

Posted: 19 Sep 2022, 11:31
by lb3361
The top white row is a page of 0xff that used as input for the spi exchange operation (send 0xff to the card, receive data from the card) The next two rows are the sector buffer. The fact that the gigatron reads constant bytes is highly suspicious since most windows formatters put things there (boot block, metadata). Those who put nothing there would have zeroes.

That said I do not understand why both cases still read a partition type 0D. Should be 0C as if one bit had been lit up incorrectly. But for this to happens one also needs to correctly read the $AA55 signature at position $1fe in sector zero. I guess I should prepare a rom file with more debug code (which is not easy because this happens in a GCL mess)....

And congrats for you VCF show.

I just attached another dev.rom with a lot more debug output in CardBoot. The screenshot below show the cardtype detection, then reading sector 0 (cmd17 0000000 ok) and checking the mbr, then reading the fat superblock (cmd17 0000003f ok) and checking that it looks like fat32, then reading the directory block and spotting system.gt1, then reading the cluster list which goes at the bottom of the screen (scanline 119), then reading the file sectors in sequence. That way, when it stops, you can see which sector was read into the buffer (scanlines 117 and 118), and check whether this data matches what you can read from the sd card with a simple dd command.
    Screenshot from 2022-09-20 09-22-16.png
    Screenshot from 2022-09-20 09-22-16.png (15.02 KiB) Viewed 65 times

    Re: Novatron

    Posted: 21 Sep 2022, 22:08
    by lb3361
    I looked again at the novatron schematics (from this thread) and I see that bus0/bus1 are connected to outputs of the U31 gal.

    I assume that these outputs are only driven when sclk=1 and /oe=0 with. At the same time /woe should be 1 to prevent the ram from driving the bus. Does this mean that bus2 and bus3 are floating when this happens. This is important because the SPI code in the rom does not sort out what's on each bus line. It simply asserts sclk, reads a byte, ands with 0xf, and checks whether the result is zero or not. Therefore, one reads a 1 if any of the bus0123 is high, without regards to which spi port is active. So if bus123 are floating, one can easily read incorrectly from the spi device.

    This works with Marcel's expansion because it pulls down all the miso0123 lines. This is a bad idea because many spi devices want a pull up instead. My solution was to make sure that when sclk=0, the bus lines bus321 are always zero, and bus0 reflects the miso of the active device. To do this one needs to have the /ss0 /ss1 signals (which U35 does not have. Note that I am using 22v10s, not 16v8s in the expansion).

    The SPI code looks like this:

    Code: Select all

    for i in range(8):
      st([vTmp],Y);C('Bit %d'%(7-i))#23+i*12
      ld([sysArgs+4],X)             #24+i*12
      ctrl(Y,Xpp)                   #25+i*12 Set MOSI
      ctrl(Y,Xpp)                   #26+i*12 Raise SCLK, disable RAM!
      ld([0])                       #27+i*12 Get MISO
      anda(0b00001111)              #28+i*12 This is why R1 as pull-DOWN is simpler
      beq(pc()+3)                   #29+i*12
      bra(pc()+2)                   #30+i*12
      ld(1)                         #31+i*12
      ctrl(Y,X)                     #32+i*12,29+i*12 (Must be idempotent) Lower SCLK
      adda([vTmp])                  #33+i*12 Shift
    If indeed MISO0 drives BUS0, then one could test the theory by replacing anda(0xf) by anda(0x1). Since this is an easy patch, I just did that in the attached rom (leaving all the debug output as well, meaning that the load is a bit slow. But it would be interesting to see if this works better. Of course this patch means that only SPI0 works, but this is a good way to know....