Jump to content
IGNORED

Icy99 FPGA 99/4A


speccery

Recommended Posts

A quick update: I have been working together with the ULX3S developers to make the icy99 implementation on the ULX3S FPGA board better. emard and lawrie have been testing the TI-99/4A core. emard added support for the screen overlay feature he is using with many other retro computer implementations. The cool thing is that this is running on an ESP32 micro controller running micropython. The overlay screen already allows loading of ROM images from SD card. When I have time I will continue to work on the core itself, for instance to add support for disk subsystem with the ESP32. I can probably reuse some of the code I created for my ET-PEB project.

 

In the process I accidentally broke my FPGA board, the primary micro USB socket became loose and broke the PCB pads in the process. Luckily I could fix this with a new micro USB connector, as it is the same connector used in my StrangeCart board. Some pictures are here in the gallery.

Link to comment
Share on other sites

I just remembered that I wanted to ask how much 9938 VDP features I would have to add to support 80 columns text mode? For example to support fbForth or TurboForth with 80 columns? I hope that this would not require too many additions. Internally my VDP core already renders pixels to a 512 pixel wide buffer, so the underlying engine has been partially designed with 80 columns in mind.

To be more specific, I guess what I am asking is that what extended registers I would need to add to support simple 80 column mode?

Link to comment
Share on other sites

1 hour ago, speccery said:

I just remembered that I wanted to ask how much 9938 VDP features I would have to add to support 80 columns text mode? For example to support fbForth or TurboForth with 80 columns? I hope that this would not require too many additions. Internally my VDP core already renders pixels to a 512 pixel wide buffer, so the underlying engine has been partially designed with 80 columns in mind.

To be more specific, I guess what I am asking is that what extended registers I would need to add to support simple 80 column mode?

 

TurboForth and fbForth set 15 VDP registers (VR00 – VR14) to effect 80-Column Text mode for both the F18A and the V9938—so, 7 additional registers.

 

...lee

  • Like 1
Link to comment
Share on other sites

2 hours ago, Lee Stewart said:

 

TurboForth and fbForth set 15 VDP registers (VR00 – VR14) to effect 80-Column Text mode for both the F18A and the V9938—so, 7 additional registers.

 

...lee

What is the reason for setting all those registers? I would have answered that he only needed to support one extra bit of register 0 (bit weight >04).

  • Like 1
Link to comment
Share on other sites

26 minutes ago, Asmusr said:

What is the reason for setting all those registers? I would have answered that he only needed to support one extra bit of register 0 (bit weight >04).

 

It looks like VR10 and VR11 are all that may be needed for the F18A (not absolutely sure about that), but the 9938 definitely needs most or all of VR08 – VR14 managed. Otherwise, you get undesirable behaviour like blinking text, etc. I believe Tim (@InsaneMultitasker) worked out these details for Mark Wills (@Willsy) for TurboForth, which is where I got them for fbForth.

 

...lee

Link to comment
Share on other sites

7 minutes ago, Lee Stewart said:

 

It looks like VR10 and VR11 are all that may be needed for the F18A (not absolutely sure about that), but the 9938 definitely needs most or all of VR08 – VR14 managed. Otherwise, you get undesirable behaviour like blinking text, etc. I believe Tim (@InsaneMultitasker) worked out these details for Mark Wills (@Willsy) for TurboForth, which is where I got them for fbForth.

 

...lee

VR10 and VR11 on the F18A are for setting name table and color table of tile layer 2. They are not needed to set 80 color mode. If the F18A is locked you will address VR2 and VR3 instead.

Edited by Asmusr
  • Like 1
Link to comment
Share on other sites

10 minutes ago, Asmusr said:

VR10 and VR11 on the F18A are for setting name table and color table of tile layer 2. They are not needed to set 80 color mode. If the F18A is locked you will address VR2 and VR3 instead.

 

Nevertheless, the settings for VR08 – VR14 were designed to allow setup of 80-Column Text mode without needing to know which VDP, F18A or V9938, was installed.

 

...lee

Link to comment
Share on other sites

3 hours ago, Lee Stewart said:

 

It looks like VR10 and VR11 are all that may be needed for the F18A (not absolutely sure about that), but the 9938 definitely needs most or all of VR08 – VR14 managed. Otherwise, you get undesirable behaviour like blinking text, etc. I believe Tim (@InsaneMultitasker) worked out these details for Mark Wills (@Willsy) for TurboForth, which is where I got them for fbForth.

 

...lee

If the program is being written to work with both the F18A and 9938 80 column modes, then yes, you need to account for VR8-VR14.  It is typically safe to reset most of these registers (i.e., load with 0x00) prior to setting VR0-7. 

 

The V9938 has a 26.5 line text mode so if people write for 30 line mode, that will exclude 9938 usage.  This may or may not be a desired outcome depending on the audience and intent. Also, if you plan to use the color attributes in the F18A 80 column text mode, the only way to mirror this in the 9938 is to use its bitmap graphics mode. 

  • Like 2
Link to comment
Share on other sites

12 hours ago, Lee Stewart said:

 

Nevertheless, the settings for VR08 – VR14 were designed to allow setup of 80-Column Text mode without needing to know which VDP, F18A or V9938, was installed.

 

...lee

Are you detecting if an V9938/F18A is present or are you setting these registers blindfolded? I think in addition to the bit in VR0 @speccery might have to support detection.

Link to comment
Share on other sites

5 hours ago, Asmusr said:

Are you detecting if an V9938/F18A is present or are you setting these registers blindfolded? I think in addition to the bit in VR0 @speccery might have to support detection.

 

The settings are unconditional. I have had no problem with the real F18A or with the V9938 emulated by MAME.

 

...lee

Link to comment
Share on other sites

I forgot that the F18A firmware 1.8 and above ignores writes to VR8 and above if 80 columns mode is selected and it's not unlocked. So that's why it doesn't hurt to write to VR8-VR15 on the F18A. On the V9938 those regs have the following meaning:

  • VR8: Mouse, light pen, sprite disable, etc
  • VR9: Vertical line count and other output related bits
  • VR10: Color table high
  • VR11: Sprite attribute table high
  • VR12: Text and background blink color
  • VR13: Blinking period register
  • VR14: VRAM access base register
  • VR15: Status register pointer

To implement a simple 80 column x 24 row mode, I think all of these can be ignored. The only issue is if software uses VR15 to set status register 1 in order to detect the V9938 or F18A, then that would have to be implemented. 

Edited by Asmusr
  • Like 1
Link to comment
Share on other sites

42 minutes ago, Asmusr said:

The only issue is if software uses VR15 to set status register 1 in order to detect the V9938 or F18A, then that would have to be implemented. 

 

I do not mess with VR15.

43 minutes ago, Asmusr said:

To implement a simple 80 column x 24 row mode, I think all of these can be ignored.

 

They cannot be ignored. I am pretty sure I tried. I would need to retest to be certain. What I have set were tweaked by Tim (@InsaneMultitasker) and Michael (@mizapf) several years ago. Below are what are set for fbForth and TurboForth:

VDPreg  fbF  TF
------  ---  ---
VR00    >04  >04
VR01    >F0  >70
VR02    >03  >03
VR03    >E8  >E8
VR04    >01  >01
VR05    >06  >06
VR06    >01  >00
VR07    >4F  >F4
VR08    >88  >88
VR09    >00  >00
VR10    >00  >00
VR11    >00  >00
VR12    >4F  >94
VR13    >10  >10
VR14    >00  >00

 

...lee

Link to comment
Share on other sites

1 hour ago, Lee Stewart said:

They cannot be ignored. I am pretty sure I tried. I would need to retest to be certain. What I have set were tweaked by Tim (@InsaneMultitasker) and Michael (@mizapf) several years ago. Below are what are set for fbForth and TurboForth:

Please, I'm not talking about what you should do but which registers @speccery would have to implement to support 80 columns. You're enabling the mouse and setting a bit related to the VRAM organisation, but speccery can ignore that if he supports neither. And then you're setting some blinking options that he probably doesn't want to support either. I think he still only needs to support the mode bit in VR0.

Edited by Asmusr
  • Like 2
Link to comment
Share on other sites

33 minutes ago, Asmusr said:

Please, I'm not talking about what you should do but which registers @speccery would have to implement to support 80 columns. You're enabling the mouse and setting a bit related to the VRAM organisation, but speccery can ignore that if he supports neither. And then you're setting some blinking options that he probably don't want to support either. I think he still only needs to support the mode bit in VR0.

 

That certainly makes sense—just as long as nothing untoward happens when writing to nonexistent VDP registers, such as what would happen if register numbers are masked to allow only the low-order 3 bits. In fbForth and TurboForth, it is presumed that the user knows whether they have an 80-column-capable VDP. If they choose 80-column text mode with a TMS9918A, the system will go off into the weeds precisely because higher-order register-number bits are masked out by the TMS9918A. As I said, if the same thing were to happen with @speccery’s VDP implementation of 80-column text mode, the above Forths will fail.

 

...lee

Link to comment
Share on other sites

3 minutes ago, Lee Stewart said:

 

That certainly makes sense—just as long as nothing untoward happens when writing to nonexistent VDP registers, such as what would happen if register numbers are masked to allow only the low-order 3 bits. In fbForth and TurboForth, it is presumed that the user knows whether they have an 80-column-capable VDP. If they choose 80-column text mode with a TMS9918A, the system will go off into the weeds precisely because higher-order register-number bits are masked out by the TMS9918A. As I said, if the same thing were to happen with @speccery’s VDP implementation of 80-column text mode, the above Forths will fail.

 

...lee

Right, so he could implement the same solution as the F18A, which is to mask to 3 bits unless the 80 columns mode is selected, in which case writes to registers >= 8 are ignored.

  • Like 1
Link to comment
Share on other sites

On 6/25/2020 at 7:47 AM, retroclouds said:

Just curious. Can I ask how you got your ULX3S board?

Did you build it yourself or is there a possibility to get fully assembled boards?

Checked, but could not find anything. Thanks

I bought mine directly from them, by e-mailing the contacts I got from @pnr. There is also crowd supply campaign at https://www.crowdsupply.com/radiona/ulx3s, and I did order another one probably around 6 months ago. Their delivery schedule has slipped, and is now supposed to be in August. I believe you can order directly from there.

 

And as I wrote this while catching up the thread, I see that the question was already answered... Self assembling the ULX3S is not an easy option, as the ECP5 FPGA is BGA chip, and there are a ton of other components on this board.

Link to comment
Share on other sites

On 6/25/2020 at 5:35 PM, Asmusr said:

I forgot that the F18A firmware 1.8 and above ignores writes to VR8 and above if 80 columns mode is selected and it's not unlocked. So that's why it doesn't hurt to write to VR8-VR15 on the F18A. On the V9938 those regs have the following meaning:

  • VR8: Mouse, light pen, sprite disable, etc
  • VR9: Vertical line count and other output related bits
  • VR10: Color table high
  • VR11: Sprite attribute table high
  • VR12: Text and background blink color
  • VR13: Blinking period register
  • VR14: VRAM access base register
  • VR15: Status register pointer

To implement a simple 80 column x 24 row mode, I think all of these can be ignored. The only issue is if software uses VR15 to set status register 1 in order to detect the V9938 or F18A, then that would have to be implemented. 

Thanks @Asmusr this is what I was looking for! I would initially be looking to implement a super simple 80x24 mode - but still something that at least some software can directly utilize, it can be made fancier later. It would be a nice addition to the icy99 code base. If it as simple as adding one more bit, this should not take long at all to implement (if I had some time,  but that is another story).

Link to comment
Share on other sites

On 6/25/2020 at 8:09 PM, Asmusr said:

Right, so he could implement the same solution as the F18A, which is to mask to 3 bits unless the 80 columns mode is selected, in which case writes to registers >= 8 are ignored.

 

Thanks for the comments @Asmusr and @Lee Stewart. I quickly looked at my code, and currently it is only looking at the 3 LSB bits for register selection, but expanding that is trivial. I actually have already extended the interface to my TMS9918 last year, so that instead of the VDP only decoding one bit from address bus, I have a 8-bit address bus and support a bunch of 16-bit registers which can be read by the CPU. For reading, in addition to reading from address 8800 and 8802,  with my VDP there are 16-bit wide registers in the range 8880..88A0, enabling reading back all registers, with proper bit shifts to have the direct VRAM addresses for all tables, and additionally the VRAM pointer can be read, the screen refresh row and column, whether the display is in the blanking area, plus some debug stuff.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Wow again it has been a very long while since the last update... I have worked on some TI-99/4A related items in the meantime, but with very little time.

 

This week I received from Crowdsource my 2nd ULX3S development board. Motivated by that, I worked a bit on the icy99 core.

 

I added two things:

- support for 80 column mode (minor mod)

- support for SDRAM (major mod)

 

The 80 column mode went almost as I hoped, in accordance to what @Asmusr wrote: enabled by bit 2 of VR0 register. However, what nobody warned about was that the interpretation of VR2 (name table base address, i.e. the base address of screen tile table) also changes. I was using TurboForth in 40 and 80 column modes to test, and the 80 column picture was just static seemingly random character display. It did display 80 columns per line with the right fonts, but the text was bogus. What I subsequently learned was that apparently with the enhanced VDP 9938 (and I assume 9958) you need to set the two LSBs of VR2 high, but they seem to to not be used (i.e. interpreted as zeros). TurboForth did this, and in my first attempt the name table address changed in accordance to the VR2 change. After some head scratching and random googling I found the critical information, and now if 80 column mode is enabled, the two LSBs of VR2 are just ignored and treated as zeros when forming the memory addresses. What this means is that there are only two bits (bits 3 and 2, weights >8 and >4) of VR2 which are actually used in 80 column mode. Thus the 80 column name table can only be located to 4k boundaries in the 16K VDP RAM. With this change TurboForth now displays properly in 80 column mode. I don't have much other software to test.

 

SDRAM: With help from @pnr who has continued to work on the ULX3S apparently for quite some time, I got SDRAM working using his controller. This is a pretty major step, and enables the development of support for extended paged memory. So I will be adding support for 1 meg of AMS memory some time soon. What I did so far was that I moved the scratchpad RAM and 32K RAM expansion from the FPGA's internal memories to SDRAM. This was mostly to test that the SDRAM interface works, and it does now. The ULX3S has 32 megs of SDRAM, so for the TI-99/4A's purposes that is more than plenty.

  • Like 8
Link to comment
Share on other sites

A few more updates. I have worked a bit more on the ULX3S FPGA board and the icy99 core.

I have found a few more bugs, fixed some, and done general improvements. Most of this is done in the platform independent part of the Icy99 core, so should be portable to other FPGA systems.

  • Text mode at both 40 and 80 columns showed some rubbish on the top right hand corner. Took a while to find the problem, but now fixed.
  • Found some picture vertical alignment issues, fixed those.
  • Took SDRAM into use for real, now cartridge ROM space is 2 megabytes, i.e. 256 pages of 8K. I could make it still bigger, as the board has loads of memory. This enabled me to test with many more programs, and I found some more problems. Megademo continues to be an excellent test case. It seems that the 5th sprite detection logic is not yet working, as the megademo get stuck. I had the same problem in the past with the VHDL version too. Also found problems with multicolor mode.
  • Joystick support was lacking, so I just mapped the PS/2 keyboard cursor keys and right control key as joystick directional control and fire.
  • I had good fun playing a bit Knight Lore after adding the joystick support. I read from @Asmusr comments that the original port had suffered a bit from performance problems, i.e. was a bit slow. No such problems with icy99, it actually runs quite a bit too fast.
  • Also played around with the 4K competition games. I didn't quite understand what to do in some of them. Icy99 runs quite a bit faster than a regular TI-99/4A, so I need to test with classic99 as well to see if some of those are just uncovering bugs in in Icy99.
  • I integrated my version of the code better to the ULX3S platform. Emard (ULX3S developer) had already integrated ULX3S to my core, but my own "base" version didn't have this integration yet. The ULX3S has a ESP32 microcontroller, and it can now load very fast very large cartridge images from SD card to the icy99 core. There is an overlay screen which enables one to select and load ROMs to load.

 

Still many things to do:

  • Audio output support
  • Cassette reading support (should be interesting from timing perspective)
  • 1M AMS memory support
  • Slow the system down to approximately original speed (optionally)
  • Filesystem support (this a bit more long term thing)
  • Port to other FPGA boards
  • Like 7
  • Thanks 1
Link to comment
Share on other sites

I think I just created my first multibank cartridge! In order to see where the bugs I experience in Megademo come from, I created a super simple cartridge to enable me to load VDPDUMP.BIN files created with classic99 on the FPGA hardware. This enables me to check if my VDP shows the correct picture when provided with a valid dump from classic99. So I should be able to distinguish between VDP bugs and system bugs.

 

Classic99's debugger has the dump RAM option, which creates the VDPDUMP.BIN file. The file length is 16k+8 bytes, and thus exceeds the max size of a non-page cartridge. 

 

I created a short assembly cartridge, which occupies only a few hundred bytes. I pad this to 4K and call it vdpload0.bin. It occupies the lower half of each bank of the cartridge, i.e. is at >6000 regardless of the cartridge ROM bank I'm in.

 

The VDPDUMP.BIN file I split into five pieces: 4k + 4k + 4k +4k + 8 bytes. The last 8 bytes I then pad to 4k as well. These 4K data blocks become the top half of the 8K cartridge image. Then I just create the cartridge ROM image by concatenating vdpload0.bin followed by a 4K data block, five times. (and for good measure pad it to 64K with a few more useless copies).

 

The cartridge program is very simple, it first switches to ROM page 4 (VDP register values), reads the 8 bytes of register values and writes them to the VDP registers. Then I go through ROM banks 0,1,2 and 3, copying from each the top 4K to VDP RAM. And voila, I have the data captured with classic99 in the VDP memory. That verifies that multicolor mode really does not work, but the first phase of megademo produces a correct image on the VDP - and the bug with that is with the rest of the system. Should have done this earlier, but good to have more generic debugging tools available.

Edited by speccery
  • Like 3
Link to comment
Share on other sites

On 6/24/2020 at 5:06 PM, Lee Stewart said:

 

It looks like VR10 and VR11 are all that may be needed for the F18A (not absolutely sure about that), but the 9938 definitely needs most or all of VR08 – VR14 managed. Otherwise, you get undesirable behaviour like blinking text, etc. I believe Tim (@InsaneMultitasker) worked out these details for Mark Wills (@Willsy) for TurboForth, which is where I got them for fbForth.

 

...lee

Yes. @InsaneMultitasker and Fred Kaal helped me to work them out. 

  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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