Jump to content
FarmerPotato

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

Recommended Posts

On 12/14/2019 at 1:42 PM, BeeryMiller said:

As far as XOP's and interrupts, please keep in mind programmers have approached multiple routes for some of their programming.  Some programs using the XOP's to do/get video data and keyboard data, while others go straight to the ports and bypass the XOP's all together.  Some even mix things up depending upon the needs or what worked for them at the time.  I'm not sure how your "Supervisor mode" would interact in these situations

 

Your first task should be to get an unmodified latest version of MDOS running.  If you accomplish that, then everything else is bread and gravy and existing programs should work.  If it is not possible to get the latest MDOS version running "as is" without modification, then there are going to be many programs that will not run and I would question how many people would actually jump on board..

All these are still definite goals in the plan.

 

I've worked out a design for robustly supporting memory-mapped access to ports in GPL and MDOS. Existing XOP or user code will find the ports there, but, XOPs could be rewritten to optimize.  At the same time, all peripherals can be reached on the CRU parallel bus. In Supervisor or BIOS mode (or native FORTH or Unix or...) I'm trying to keep everything on the 16-bit bus pure memory, while using CRU for all peripherals, like a TI 990. However, depending on mode bits in the FPGA, any address in any page can be carved out as a port, not RAM. Or a CRU parallel range can map to a VDP port or other 8-bit device. (CRU parallel uses 8 or 16 data lines in one CRU cycle.)

 

An exciting feature that this enables, is that a GPL window at >4000 can be opened up to access an external P-Box (or any 21-bit address out there from MDOS.) This will require a new flex card. Or >6000 is opened up for real cart access, instead of just accessing a memory image or the GROM simulator. 

 

I made a new block diagram that shows the relationship between a "native" 16 bit bus and the 8-bit peripherals (including cart port and P-Box.)

 

So, all XOPs and direct port access should "just work" when running an original MDOS binary. The BIOS will set all the mode bits before transferring into MDOS.

 

On 12/14/2019 at 1:42 PM, BeeryMiller said:

As far as a cartridge port, myself, I am not particularly keen on a cartridge port.  Are there really any cartridges that users wish they could run on their Geneve?  Outside of potentially DragonSlayer and perhaps Matt's Finalgrom cart for the TIPI, those would be the only two cartridges.  From what I read, it took the developer several years to reach the point where it was ready for release.  Is there really any other ports that would be in cartridge form only that would be used on the Geneve 2020?

 

I don't want to exclude anything that comes along in the future -- therefore physical ROM and GROM will be accessed through one of the 8-bit slots (well two.) Also, I really want to plug in physical things. And this would make CSAVE very convenient (as if everything isn't dumped already...)

 

All the 8-bit peripherals will likely be separate cards. If you don't need one of them (cartridge.. sound card.. second VDP..) you can leave it out. I'm doing this so I can revise (or deliver!) each peripheral one at a time. So, you could just omit the cartridge port hardware. The P-Box interface is at the bottom of my list, but I consider it essential to provide access to existing disk controllers.

 

The architecture is looking more like a PC that has some 16-bit slots (AT) and some 8-bit slots (PC/XT). The two backplanes are generic, so, I could easily make one longer with more slots. Or a short (4") one which would be very cheap. The CPU is a plug-in card as well. Repairs or updates will be easier. 

 

Thank you for your feedback during the design process!

 

-Erik

(Block Diagram follows)

  • Like 2

Share this post


Link to post
Share on other sites

In my opinion, having a kernel/user mode selection should also mean to prevent any direct access to devices, even if that means it will slow down things. This also includes making LIMI 0 illegal for user processes. The XOPs are our system calls, and they should be mandatory for access.

 

But there could be a compatibility mode for older programs that directly access devices. (Yes, I also wrote such programs.) I think you can permanently stay in supervisor mode if you do not set the bit in the status register using LST or RTWP.

Share this post


Link to post
Share on other sites

Geneve 2020 Block Diagram

 

BlockDiagram.thumb.png.489003278465b4b0b5cb7f547d826940.png

 

Notable features of this design:

 

The CPU and peripherals are all plug-in cards to a backplane. Easy to repair and update. Even the CPU is a plug-in card. 

 

There is a 16-to-8 bit bridge. This lets 16-bit cards run at full speed, while access to 8-bit devices (VDP etc) goes through a bridge, similar to the 4A.

 

You can have 1 or 2 VDPs. Suggested configuration is a V9958 and an F18A (mk1 or mk2.) But two V9958 is an option.

 

8-bit bus can support a cartridge slot, and a P-Box interface (new flex card.)

 

Sound includes an analog output path (mono), or digital mixing to 2 or 4 (analog output) channels. The SN76489 (original sound chip) is not included in digital, but can be emulated.

 

FM card includes 2 OPL3 or 2 OPN-A type chips from the 1990s. They are either simple stereo analog output, or the far more capable digital path. This gives 12-voice polyphony or 24-voice in OPL2 mode.

 

(I forgot to draw in the 2 SD card slots. These are on the FPGA too.)

 

 

  • Like 5

Share this post


Link to post
Share on other sites
3 hours ago, mizapf said:

In my opinion, having a kernel/user mode selection should also mean to prevent any direct access to devices, even if that means it will slow down things. This also includes making LIMI 0 illegal for user processes. The XOPs are our system calls, and they should be mandatory for access.

 

But there could be a compatibility mode for older programs that directly access devices. (Yes, I also wrote such programs.) I think you can permanently stay in supervisor mode if you do not set the bit in the status register using LST or RTWP.

That's interesting, that there could be a compatibility mode, plus a strict MDOS mode. I'll think that through.

 

Aside from whether strict access to ports is imposed: (I'm just thinking of VDP)

 

Any XOPs, interrupts, and LIMI instruction will always trap into Supervisor control first. Supervisor can ignore a LIMI from GPL/MDOS as needed. (If it doesn't want GPL to change the interrupt mask) The real INT1 to the real 9901 traps to the 64K EPROM, and lets the supervisor do what it wants to first. Then the supervisor branches to the MDOS/GPL INT1 vector.

 

Privileged(supervisor) mode runs in a plain 64K space with MS=0. There is 32K of EPROM and 32K of RAM (maybe some simple paging, if I need that.)  (LDS and LDD can read/write to/from any page in the memory mapper, relying on the ST8 Map Select bit flipping.)

 

I hadn't considered running anything outside that 64K as supervisor. But I was confused about the ST7 Privilege and ST8 Map Select bits, thinking they were the same thing.  I see now that the Supervisor can RTWP with PRV still active(0) and MS set. This would return into the user memory map with privileged mode.

 

Back to VDP:

 

I guess "strict mode" could detect access to a port (VDP etc) and drop to the debugger; however, letting it go ahead might be perfectly fine! Unless you wanted some effect like, an MDOS program is left running but its screen is hidden by something else...  I don't think this would end well (how would it be told to re-draw itself again?) 

 

Double-buffering all the VDP accesses in a shadow VDP is not really feasible! Maybe just for text mode? Or, it's more likely you would want to freeze one GPL environment (with VRAM saved to main memory), switch to MDOS, then switch back. Another option is to use two VDPs across the two environments. 

 

All this memory-mapping of ports is configured by bits in the FPGA (and memory mapper page registers). If the bits stand for a certain mode, a memory cycle goes to some i/o register, if not, it is just memory access.

 

It might even be possible to filter some access in simple ways.. like not letting a user-space program turn off the IE0 bit in VR#0 (user programs can't disable the VDP interrupt) (this is actually messy because the sequence is 00 87 to VDPWA. After recognizing a >80 to VDPWA , it's too late to catch the previous byte. Maybe the fpga could just queue up a second register write to put the IE0 bit back. Not going to worry about that for now. Maybe the Supervisor doesn't care what you do with VDP INT1, if it has no use for a 60 Hz interrupt.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Now for the status of the V9958 board bring-up:

 

I found some bugs in the PCB. Fortunately I could work around them in software (mixed up pins etc). I had to unscramble and scramble the pins of all 16 I/O lines (that was a surprise) and I had the '138 address inputs wired backwards. 

 

Verified that vsbw and vsbr code drives the V9958 pins correctly. Checked timing and pulse widths.

 

Still no RGB out. WAIT and INT are not right. I enabled these things in VR#0, VR#1, VR#25. It must be that vwtr is unsuccessful.

 

Memory test of 0-3FFF is a success. Setting the address bank in VR#14 does not switch banks. Ergo, vwtr is broken.

 

I spent hours checking csw-csr timings (page 121-124 in V9938 book). There are some big gaps of 2us and 8us that must be met on the V9938, and I put those in. 

 

So, what I have is a set of FORTH words for vdpinit, vsbr, vsbw, vwtr (broken), setting graphics modes, and some memory tests. These run in the FPGA MeCrisp FORTH, typing on the high-speed serial port. 

 

I kept a list of bugs and changes, for PCB rev2.

 

I consider it a good weekend, since the memory tests pass, and I know a lot more about the V9958.
 

-Erik

  • Like 4

Share this post


Link to post
Share on other sites

Progress with V9958 board bring-up:

 

RESET fixed,  VWTR works, RGB out shows a 15 kHz pattern, and RGB levels change with VR#7 background color. Yay!

 

Memory tests for 16K still pass. Setting R#14 , the 3 upper bits, not so much. I made sure the 16/64K bit was set.

 

With all reads/writes working, I sped up memory access time.  I'll aggressively move it to the V9958 limits.

 

VDPSTA reports 9F: the INT bit, no 5th sprite bit, but Fifth Sprite#31. So far so good.

 

Issues

 

INT is stuck low. It is enabled by IE0 in VR#1 (same as 9918) and I tried an endless loop to read VDPSTA (clears INT when read). INT stays low.

 

WAIT* is stuck low (V9958 feature, aka READY). It is enabled by bit $04 of VR#25. 

 

Bug Fix: RESET

 

The 9958 datasheet said "RESET low pulse minimum width 10 ms"

 

I soldered in a 1 Mohm and 1 uF cap for the R-C on the RESET switch. My RESET pulse was, dutifully, 10 ms of low. After rising to around 1.5V, the 50 uA current charging the cap was diverted into the chip input. Stuck there! Makes sense now... I changed the resistor to 1K for a RESET low pulse of 10 us. The 10 ms is certainly a typo. I could not find the value in the 9938 book, but it is 1 us for the 9918.  Fixed.

 

Next up

 

Going back to work on analog RGB and composite video.

  • Like 6

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