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 6

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

If I could get LS610 memory mappers for $2 a chip, I might want to put 4 of them in Geneve2020.

Using vintage chips is a goal. Otherwise I'm using a $8 CPLD to replace them.

 

 

Why four?

 

 

For starters, the Geneve with 9995 has an 8-bit bus. Reading a word from page registers at >F100 means 2 reads of separate 8-bit registers at >F100,>F101.

Ditto for writing. MDOS assumes fast context switching by doing four MOV to save/restore the registers two at a time. 

 

The 9900 and 99105 read/write 16 bits. Without nasty multiplexing, wait state generating circuits, there's no way to read and write 2 registers in that MOV instruction. Unless you have TWO LS610 chips! Then one holds the odd page number, the other holds the even page number, both are attached to one half of the 16 bit bus. Hooray. This is assuming you want only 8 8K pages.

Using just 8 bits of the registers gives you 256 * 8K = 2MB of address reach.

 

Problem solved by 2 chips, right?

 

Now I'm going to assume a SECOND row of LS610 to extend the registers!

 

The LS610 registers are actually 12 bits.  Each register occupies 8 bits in one LS610, wasting 4 bits. I want all those bits! But in the above scheme, every write access would destroy the upper 4 bits (unless you could somehow loop them around. YUCK. You can't count on read-before-write to capture them.) 

 

The  SECOND pair of LS610  holds more bits! When read/write at >F100, that chip stays silent, retaining its value. When accessed at a different, word address, the read/write data is multiplexed in a different way, to load one 16-bit even register or one 16-bit odd register.

 

Picture:  16- bit stitched-up registers spread across four LS610s (wasting 4 bits per chip, and  using only 1/4 of the registers in an 8K page scheme)

E1 E2
O1 O2

E2 E1
O2 O1

MOV @F100,R1
* R1 is from E1,O1

MOV @NEWPORT,R1
MOV @NEWPORT+2,R2
* R1 is from E1,E2
* R2 is from O1,O2

 

The upper half being a "base" address for the MDOS instance, that does not change. Four of those bits gives a reach of 32MB, which ought to be inexhaustible.

 

I use the other bits for status flags--currently I want 3 status bits-- namely read-only memory (ROM), some ports are memory-mapped (SPAMM), and p-box pass thru page (PBPTHP).  But there would still be 1 bit left, and 4 wasted, in the upper register!

 

(I have not thought of a way to get 4K pages in this scheme... wasting half the registers.. actually 75%, so 2K pages could be wished for. But hopeless.)

 

So that's the scheme using four LS610s. It's pretty crazy!

 

I will probably just use the CPLD to implement 16 16-bit registers. (I also looked at a 4x4 array of LS670 4x4 register files to do that. Blearg. Might as well use 4 8K SRAMs. Gross.)

I'd like to use real chips, but not if breaks compatibility or gets stupid crazy. Doing it in CPLD allows other magic things to happen, like fast map switching, but I'm not sure if I want to be a purist or not about that.

 

Why 32MB of address reach?

 

You can get new 1MB,4MB, or 16MB SIMMs in a pair. 2MB for starters, one MDOS. 8MB enables switching between two or more... or implementing a separate RAMDisk or giving GPL SAMS memory that allocates outside the MDOS space. (Howver , the price difference is $10 for 2MB, $30 for 32MB brand new, or find them used.)

 

 

  • Like 2

Share this post


Link to post
Share on other sites
14 minutes ago, FarmerPotato said:

If I could get LS610 memory mappers for $2 a chip, I might want to put 4 of them in Geneve2020.

Using vintage chips is a goal. Otherwise I'm using a $8 CPLD to replace them.

Have you seen eBay item 143265206181 - $4.40 for two 'LS612s. Same as the LS610 but without latched outputs I believe - may work for you.

Share this post


Link to post
Share on other sites

Since there was no status update in May:

 

Status June 10

 

The CPU board is arriving from SEEED next Monday. Then it will be time to assemble and debug it. I will test it with a NOP (>1000) hard wired, called "free running."

 

The BIOS memory card is routed, but not sent, pending some QA. This will hold the initial software in EPROMs and provide some RAM.

 

The CRU/Serial 9901/9902 card must be started over. It was once integrated on the CPU card.

 

The 8-slot backplane is here. Everything will be based on 160x100mm Eurocard standard, Cards can be 100x100mm if you like.  In  fact, the backplane is an ECB-Kontron compatible backplane! As a result, I anticipate the ECB Disk IO V3 off-the-shelf will provide DSDD floppy and IDE access, but require re-writing drivers (The supplied driver is in Z80.)

 

Some parts of the 8-slot enclosure is here. It is going to be super classy, but cost $150 including backplane. Optionally, you can put the naked backplane into a PC tower. A 12-slot backplane and enclosure is possible, or a 4-slot (I have to combine some cards to make that viable).

 

I am going to give a PCB order to Aisler - they will make one for about $40 shipped to me, in US or Germany, not much more than $30 with shipping from China like SEEED Studio. Or $80 for a 10x10cm from OSHPark, yikes.

 

Features implemented:

 

The 16-bit bus and 8-bit peripheral bus (VDP, sound, Pbox etc) are unified on one backplane. Access to 8-bit cards will be direct when memory-mapped ports are enabled, and always possible through CRU byte-or-word-parallel (two cycles vs one for memory mapped).

 

The CPU card drives 15-bit address and 16-bit data lines and all other CPU outputs to the bus. It adds several useful signals like IO parallel and serial, and generates some ECB specific signals for compatibility with Z80 cards.

 

The CPU card supports external Macrostore and attached processor interface (think floating point coprocessor.) It supports external RESET and NMI buttons.

 

The BIOS card decodes Macrostore access (integrated into the Page 0 EPROM space, not a separate page.) It supports supervisor and user memory spaces. It supports one 16K ROM page 0 and one 16K RAM page 0 always present in supervisor mode, and bank switches additional 16K pages of ROM and RAM (currently 8 pages of ROM, 16 pages of RAM.) It also has nice LEDs.

 

Not implemented

 

Plans for the DRAM card amd memory-mapping are wired into the CPU and BIOS cards.. the DRAM card will have the memory-mapper, making a 32MB user space.

 

VDP is still sitting on my desk. It generates 15kHz different RGB screen colors.. But I have not got it to sync with the Acer monitor yet. It will require a revision or a bus adaptor to use.

 

FPGA is back to the drawing board. However, it's becoming less necessary, as more functions are implemented in real chips. The bring-up system will run software without it. However, the SD card filesystem is in my FPGA so...

 

I have found a ready-made ECB Disk IO V3 floppy and IDE controller. It is uPD765 compatible (IBM 360K). It's not too different from Thierry's IDE, but drivers will have to be written.

 

 

  • Like 5

Share this post


Link to post
Share on other sites
4 hours ago, Stuart said:

Have you seen eBay item 143265206181 - $4.40 for two 'LS612s. Same as the LS610 but without latched outputs I believe - may work for you.

Yeah, 612 would be fine. I would not use the latch. (or is it the 612)

 

I think that's 4.40 each chip.

 

Four of the DIP40 would take up a lot of space. The F package would be nicer. 

 

Actually Rochester has them new, min qty 51 at $5

https://www.rocelec.com/search?q=74ls612

 

But... it's likely I would move up to reproducing it with, at least, an ATF1504 at $4. But with the lower Atmel parts, I found the WinCUPL tool compile/run test vectors  to be  a miserable process. Still, these are not too overpowered.

 

 

Share this post


Link to post
Share on other sites
9 hours ago, FarmerPotato said:

Four of the DIP40 would take up a lot of space. The F package would be nicer. 

 

Actually Rochester has them new, min qty 51 at $5

https://www.rocelec.com/search?q=74ls612

 

That's a chip I hadn't looked for at Rochester yet. I have an account there, and that price is in the range I've had to pay for chips in the past from other (not always reliable) sources. I'll have to order some of them before my current batch runs out. . .I think I'm actually down below 50 again.

Share this post


Link to post
Share on other sites

 

On 6/10/2020 at 5:12 PM, Stuart said:

Have you seen eBay item 143265206181 - $4.40 for two 'LS612s. Same as the LS610 but without latched outputs I believe - may work for you.

Aha, was your point was the latched outputs would help in creating a loop-around multiplexer? Or just that chips can be found?

 

Share this post


Link to post
Share on other sites

A short status update for June and July.

 

I've put a great deal of effort into mechanical and thermal design.  The goal is to produce an affordable metal enclosure for a complete system. While also preserving the ability to put the electronics into a PC ATX case.  I'll have photos of the actual thing soon.

 

I've used PC97 motherboard-to-port header pinouts wherever possible. So there is a chance that in an ATX case, the standard PCI card brackets will be usable, for plugging in PS/2 keyboard, mouse, RS232, VGA, etc. I used the AC97 standard audio, 10-pin motherboard cable, to the front panel audio jacks.  But my enclosure provides all those ports in its I/O panel. I was inspired by FRONTX.COM.

 

The whole system will fit into a 10x8x5" steel enclosure, with power supply and fan, adding about $100. That's not unreasonable for what you might spend on a new PC ATX case with power supply. But you could still bring your own ATX case. It needs the 20-pin ATX power connector, and one 4-pin "Molex" power cable.  

 

The CPU card is built and running. It doesn't do much without memory or communications. The PCBs for those are awaiting a serious QA review. When those are made, the minimum viable system will be ready to test and debug. It will have serial console (DB9) and PS/2 keyboard/mouse and 256K of static RAM.  Everything else is still in a design stage, like the 32MB memory card, FPGA, SD cards. 

 

I had my technician make the IceZero, to prove we could build a board with a TQFP144 chip, 0.6 mm pin spacing.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
30 minutes ago, FarmerPotato said:

I had my technician make the IceZero, to prove we could build a board with a TQFP144 chip, 0.6 mm pin spacing.

 

 

You have the perfect housemate--one that actually engages with your hobbies.  :)  :)  And can solder too. . .I wish I could get mine to do that, as I'd be able to finish a lot more boards.

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites

Some more fun details:

 

The system uses a Eurocard backplane with 8 Eurocard slots (160x100mm).  4 slots will be filled by CPU/CRU, I/O, FPGA/DRAM, and Video/Audio. (I'm actually making them separate, first.)

 

The EuroCard bus is compatible with retrobrewcomputing.org I/O cards (but not memory). The CPU card maps a range of CRU byte-parallel operations (LDCR, STCR) to the I/O cycle typical of a Z-80 or 8086 (asserting the /IORQ pin).  For instance, the DiskIO/3 card, built for a Z-80, could be addressed by CRU. DiskIO/3 provides a u765 floppy chip DSDD, and IDE interface. It's my hope that I can leverage that DiskIO/3 card, and in the other direction, give something back. Other far future expansion cards are a P-Box interface, for ultimate compatibility.

 

  • Like 5

Share this post


Link to post
Share on other sites

Cross-posting from IDEA thread:

 

 

3 hours ago, Nick99 said:

 

Ok, then there is a possibility to get the TIPI. Great!!! 

As far as I understand the SDD99 (that´s not ready just yet) will some day be Geneve compatible, when and if it will be made as a PEB-card(?). 

I know you mentioned a future connection to the PEB on the Geneve 2020, but in that case, could it be possible to connect the side car SDD99?

Just speculations and curiosity... 😃🙈

 

 

Well, side car and Pbox flex cable are different things, but carrying most of the same signals . The Geneve2020 "hardware compatibility" interface card would have the 16 to 8 bit multiplexer like the 4A, generating wait states, and include the buffers/drivers like the P-box flex cable foot. Then there would be a 50-pin SCSI cable to a new card in the pbox, which replaces the flex interface card.

 

I think of it as the "8 bit compatibility card" and it would supply physical GROM/ROM from cartridges as well on the 8-bit bus. Actually, I hope someone else will make it.  (It is totally optional. You get 8-bit vdp, speech and sound from the MSB on the 16-bit bus.)

 

Making a sidecar port might be a matter of same signals, different cable. I dunno what gotchas there might be. 

 

How it will work.  The memory mapper stores a bit, per page, that goes out over the backplane to indicate an access to an external 8-bit bus multiplexer. It's called the PBPTHP, for P-box Pass Through Page.  When a page has the PBPTHP set, is mapped in at an address, say >4000 in GPL mode, and there is a memory access to >4000, the PBPTHP line is asserted. You can also set the PBPTHP on a CRU range. Seeing the PBPTHP, the P-box controller would run the memory cycle out to the Pbox. So, if you had a Geneve/Tipi in the P-box, then you would set things up to assert the PBPTHP when you want a Raspberry.

 

image.jpeg.d67aad8dd8d99545ed44ca1c1adac6f8.jpeg

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Making a status update.   I have not had much time for hobbies in August. 

 

I have put a lot of effort into physical design, because I really wanted to.

 

I made paper prototypes of the Front Panel where the common ports are. Some will finally migrate to the back, like VGA and printer ports, but SD slots, joysticks and PS/2 belong in the front.

 

This is ready to get lasered out of wood, or acrylic (the intended final form) but Covid makes that a big deal to go do. (At Hackerspace, must wipe down computer, laser, and work area before and after use.)

 

The "floor plane" is also paper prototyped and ready to laser. It holds 8 card rails (Bivar), the front panel PCB (including ATX power connector) and has ventilation slots for air to flow up between the cards. A laptop blower  fan points into there. 

 

I have re-routed the CRU and BIOS boards a couple times with changes. The CRU has one master connector for I/O that goes to the front panel PCB. A riser from this PCB has the physical ports sticking out.  The front panel PCB also has individual box headers for peripherals that follow PC97 standards like RS232, VGA, AC97 audio.  So there is the alternative of plugging in PCI slot brackets, the kind that come with ribbon cables, if you want to put this in an ATX case.  (If you bought an F18A, you are familiar with the VGA slot bracket with ribbon cable. That's what I'm talking about.)

 

I have not found any standard PCI slot bracket pinout for PS/2, though. There will be a header for the GamePort bracket, to which you can hook up one of the 15-pin MIDI adaptors. I verified that you can still buy all these PCI slot brackets for cheap.  (FWIW, the internal cards also have holes at the PCI spacing.)

 

I had a neat idea. There are now two TMS9901 chips.

 

One of them is mapped at >2000, privileged space. It handles the real interrupts and some peripherals like PS/2 and SPI for the BIOS.

 

The other is mapped at >0000 for compatibility. Its pins are wired to the actual joystick pins and 4A keyboard (if you want one, there is a connector kit.) The 2 interrupt status bits are fed to it by the other 9901. The MDOS keyscan bit and others are connected, too. I am trying to achieve maximum compatibility with MDOS/GPL in real chips, while offering a new BIOS layer that uses all the interrupt levels of the 99105.

 

The 9901 timer is also there for user access. The one at >2000 is reserved for the BIOS, which might use it to implement multitasking.

 

I still need a way to spoof the 4A keyboard lines from the PS/2 keyboard-- I imagined the FPGA doing that--it should look like an 8-byte RAM. But now there is a real 9901 onboard, not a simulated one. The goal is maximum compatibility with games that directly read the keyboard, without introducing an I/O coprocessor.

 

Audio/Video

 

I'm not putting effort into this now (I want to get back to the 9958). But here is an idea I had.

 

The audio card--packed with goodness--on its current PCB layout it has room for 6 more 1/8" jacks in front. A TL084 op-amp and a jack can be as cheap as 20 cents.  It already has the AC97 connector for the standard LineIn/Mic/Headphone-LineOut.

 

I had the idea of making each separate analog signal output on its own jack. (otherwise they get mixed digitally.) So you could take just the Speech output, pass it through your favorite sound effect module, and then route it back to LineIn. Then, in the digital mixer (Speech has both digital and analog) mute the Speech, and pass LineIn through. Another thing you could do is take any of the "dry" sound chip output channels and put them through your own reverb unit or mixer.

 

 

Four months to go or I'll have to call this "2021".

 

  • Like 7
  • Thanks 2

Share this post


Link to post
Share on other sites

I like the idea of separate analog signal output jack, it opens up for som fast and simple connections to the studio gears as you mentioned. 

Yeah, and when I read, "and then route it back to LineIn" I feel this tingling feeling of satisfaction in my stomach. 😂👍

 

thanks for the stats update, I always enjoy reading about your ideas and progress!

 

  • Like 1

Share this post


Link to post
Share on other sites

I know, 78/79 tech in the 4a, but it would have been really nice to have had two sound chips for stereo.

One of my bucket list items, somewhere between when I retire and before I die, is hooking up my Forti Sound Card to four decent speakers and playing some of the demo music.

 

  • Like 2

Share this post


Link to post
Share on other sites


I have finally, again, wrestled WinCUPL into working for me.
 
WinCUPL is a 1990s to Windows 2000 era tool that compiles CUPL logic into Atmel PLDs. It covers the GAL16V8 range often found in P box cards--there is one in Geneve 9640. Its output works with the TL866 programmer. 

 

The ATF22V10 is a PLD still in production, and is a superset of the GAL series. It has a whopping 10 bits of registered outputs, and 12 input-only pins. It fits the category of vintage part, and has just enough ability for the job.

 

Pictured, are the WinSim test vectors, for my BIOS card bank-switch register. The test sets and clears 8 CRU bits, then writes >05 and reads that back again.

 

The ATF22V10 chip is perfect as an 8-bit register. On a card, it can replace the 74LS259, 74LS151, 74LS138, and 1-2 other logic chips--the typical implementation of a CRU register with up to 8 bits.

 

Inputs: Address bits, CRUOUT, SERENA*, WE*. 
Outputs: LED0, 7 bank bits, CRUEN*, CRUIN

 

Here, it is doing the job of CRU address decoder. It detects a base of >2000 (aliased at >6000 because I needed to squeeze in just one more input.) So the CRU base is programmable by flashing the PLD. 

 

CRUEN* (flipped to positive logic inside the chip) outputs this card select, which is useful for switching on a tri-state bus driver (74HCT125) to bus line CRUIN. CRUIN reads back a bit from the register.

 

Another way to set CRU base is with DIP switches and an 8-bit comparator LS688 (this is used on every PC ISA card.) The LS688 costs almost as much as the ATF22LV10C. 

 

One input, SERENA*, is already decoded to detect a CRU bus cycle, not a memory cycle, with address in the range >0000 to >7ffe. This is one of my bus signals, and potentially every card needs it.

 

In the bank register, I use 3 ROM bits, 4 RAM bits, for 8 and 16 banks resp. The BIOS memory map is:

 

0000-3ffe ROM bank 0    (ROM here means Flash or EPROM)
4000-7ffe ROM bank 0-7
8000-bffe RAM bank 0
c000-fffe RAM bank 0-15

 

An HCT156 gates the bank bits to the upper memory chip address bits.  It outputs either the ROM or RAM bank bits, or all 0s. A14 turns banking on or off, to keep bank 0 fixed in place (A14 is A1 on the TI-99/4a, but I count up from A0 LSB.) A15 selects ROM or RAM address outputs. It is convenient to route the upper address bits across ROM and RAM, so one HCT156 can do the on/off job for both.

 

Also, this is a 16-bit bus, and A0 selects even/odd byte memory chip. Each ROM has the full image, so A0 is hard-wired 0 or 1.  This cuts usable ROM in half, but there is also just one image to worry about (no splitting the code into odd/even image.) This way you can't mix up the chips in the wrong slot. So two 128kx8 ROM give 128K of usable ROM, and two 128kx8 static RAM give 256K of usable RAM.

 

The BIOS ROM holds supervisor code: the interrupt handlers, boot code, MDOS/GPL launcher, MDOS XOP patches, other routines for OS bootstrapping, system calls and high-level memory allocation, zlib and riparian animals.  Also 99000 macrocode. 

 

(Macrocode is entered by executing an "illegal instruction" ie user defined opcodes. For example, opcodes for 32-bit arithmetic or floating point. Macrocode is a separate address space, and a 99000 system might select a separate external ROM for it. But I chose to unify BIOS and Macrocode ROM into Bank 0 for convenience.  RAM bank 0 can also contain macrocode.)

 

BIOS ROM/RAM is turned off when Map Mode is enabled. In Map Mode, the full 32MB is paged in 4K chunks, similar to SAMS, except the LS612 is replaced. Map mode is turned off, and BIOS is turned on, by any interrupt (including RESET). Interrupt handlers in BIOS get first crack, and can forward the interrupt to an MDOS or GPL handler.

 

With the PLD all sorted out, the BIOS card is off to the PCB house.
 

image.thumb.png.6f7301fc1fe3d6fcb70a7ae229072dff.png

 

Source: https://gitlab.com/FarmerPotato/geneve2020/-/tree/master/kicad/bios

 

image.thumb.png.b3f772fc9d1c7520c82d11e04f8c4bb8.png

 

  • Like 8

Share this post


Link to post
Share on other sites

>I have finally, again, wrestled WinCUPL into working for me.

 

How did you tackle that job?

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 8/28/2020 at 7:02 AM, dhe said:

>I have finally, again, wrestled WinCUPL into working for me.

 

How did you tackle that job?

 

 

WinCUPL was last supported on Windows  XP in 2003. Documented bugs and crashes on Windows NT of the time. So, it crashes a lot on my Windows 7 machine. I think it behaved the same on Windows 10.

The fact that Atmel (Microchip) still makes these chips and provides the old software... well... its something.

 

It is two programs, WinCUPL to enter equations, and WinSIM to run the tests. Frequently, they open each other's files and the other one crashes. So I try to get as far as I can in WinSIM until I absolutely have to go back to WinCUPL to make code changes. There is a lot of mouse clicking on the graphics *output* boxes to enter *input* data like Clock, Input High, Test Output Low. Also, the chip I'm using is fully documented for the DIP package, but I need the PLCC package, and I gave up on making WinSIM recognize the PLCC pin numbers. Once I got all the tests to pass on the DIP package, I translated to the PLCC pin numbers and it passed too. Yay.

 

Plus, the output window is blank after tests run-- it doesn't draw any graphics--you have to click or arrow around, to force it to redraw one column at a time. Probably a Windows XP compatibility thing. I don't know if there are some modes I can turn on in Windows 7.

 

So, not a lot of fun, for a minor but necessary feature.

 

I hear there is a CUPL compiler for Linux, I just haven't found enough info.


LabVIEW

 

NOW I'm in an even worse task: Test the actual, programmed chip, using LabVIEW 2013 to run my logic analyzer. Programming LabVIEW to read WinSIM files and run through the same tests. I've wanted to do this for a long time, and it will quite valuable going onward: it will work with the 99105 cpu or FPGA or video or audio card. But, to put it mildly, LabVIEW sucks. At least it doesn't crash. It took me all day Friday to make LabVIEW do the equivalent of this Perl code (which I can write in a minute here), just to read one of the WinSIM files:

while(<>) {
  chomp;
  if ($_ =~ /PIN\s+(\d+)\s+=\s+(.+)/) {
   push(@pins, $1);
   push(@names, $2);
  }
  if ($_ =~ /\%END/) { break; }
}

But LabVIEW is what I've got. I can use to control the logic analyzer outputs and read vectors of inputs. I can use it to compile test plans onto a Xilinx FPGA, with all the inputs and outputs I could wish for running at full speed. It just sucks to program it to do what would take a few lines in C.   AND I don't have all the C interfaces to work around it. 

 

And yeah, I was a professional LabVIEW programmer, and I hate starting from scratch.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 8/27/2020 at 8:57 AM, TheBF said:

What ROM bank will Forth live in?  :) 

All of them! Bank 0 for starters. I hope that entire upper layers of the BIOS will be FORTH code.  My device driver is written in FORTH.

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

https://www.maketecheasier.com/create-symbolic-links-windows10/

 

 

Edited by wierd_w

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