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

[+FarmerPotato]

16 hours ago, mizapf said:

Do we really need a triple cartridge slot? ... Seems as if I already got used to the typical Geneve handling, i.e. copy the cartridge to hard disk and load it from there. One slot, and a csave program.

 

Also, I'd add a RESET switch, and a NMI switch (aka LOAD).

 

I'd rather not have a single key QUIT. There is a reason for requiring a multi-key gesture for resetting. ?

No, not really needed... but it would be fun to have multiple GROM bases.  Ksarul likes the cartridge expander.

 

QUIT was a joke. FN = out to be enough. (keys labeled FN can be purchased but not FCTN)

 

I have no idea what the standard 101-key "SysRq" is for, but I included PrtScn as "Print"

Shift-Print would be the "Turbo" speed control for GPL.

Shift-Break would be NMI (debugger key?)

Reset... maybe that's below the cartridge port? I'm not sure how the Reset will behave--maybe with an on/off button too.

 

This is all playing around.. what are good keys to have?

 

The knobs are for MIDI editing. I want up to 10 knobs, maybe above the keyboard?

 

What do you think, analog joystick or arrow keys? The analog joystick can substitute for a mouse (it's the XBox/Playstation mechanism.)

There is actually a button in the joystick hat, but I threw in two 24mm Japanese mini-arcade buttons.

 

 

I deleted the RGB and DVI ports, and put in VGA and mini-DP. Really anything could happen -- undecided whether video should be 9958 or F18A or both. 9958 RGB could use that connector, if not actually VGA signal. Oh, and I fit in some SD slots. Standard size SD like in FlashROM will be standard media. At least 2 SD slots, one for booting, other for swapping. Unless one of each microSD and SD? That would actually be easier to put on a riser, with microSD below SD.

 

[Tornadoboy]

How about an "Oh Shit" key? That's something PCs have been in desperate need of since their invention!

 

Jokes aside, I'd go with the arrow keys, I think most people would rather just plug in a regular mouse than use the joystick as it'll be awkward to use the buttons like that. 

Edited November 25, 2019 by Tornadoboy

[RickyDean]

1 hour ago, FarmerPotato said:

No, not really needed... but it would be fun to have multiple GROM bases.  Ksarul likes the cartridge expander.

 

QUIT was a joke. FN = out to be enough. (keys labeled FN can be purchased but not FCTN)

 

I have no idea what the standard 101-key "SysRq" is for, but I included PrtScn as "Print"

Shift-Print would be the "Turbo" speed control for GPL.

Shift-Break would be NMI (debugger key?)

Reset... maybe that's below the cartridge port? I'm not sure how the Reset will behave--maybe with an on/off button too.

 

This is all playing around.. what are good keys to have?

 

The knobs are for MIDI editing. I want up to 10 knobs, maybe above the keyboard?

 

What do you think, analog joystick or arrow keys? The analog joystick can substitute for a mouse (it's the XBox/Playstation mechanism.)

There is actually a button in the joystick hat, but I threw in two 24mm Japanese mini-arcade buttons.

 

 

I deleted the RGB and DVI ports, and put in VGA and mini-DP. Really anything could happen -- undecided whether video should be 9958 or F18A or both. 9958 RGB could use that connector, if not actually VGA signal. Oh, and I fit in some SD slots. Standard size SD like in FlashROM will be standard media. At least 2 SD slots, one for booting, other for swapping. Unless one of each microSD and SD? That would actually be easier to put on a riser, with microSD below SD.

 

Awesome... drool...drool!!!!

[+FarmerPotato]

OK, arrow keys are back, joystick out.

 

But for adding a permanent input device to the console, check out this Blackberry Trackball module.

 

BTW, I'm thinking of the CX5M, an MSX machine from 1986, in the background.

 

[ti99iuc]

you can also think about the Enterprice64/128

[+mizapf]

Why not go for a standard PS/2 keyboard instead of the console keyboard? (I'm living with a Geneve for too long, obviously ... )

 

The point with the cartridge slot is that back in those times when I got the Geneve, I was more than happy not having any of those flaky cartridge ports anymore. Of course, here I could then choose the dump solution and just leave the slots unused.

[wierd_w]

I am rather spoiled by the 101 key layout, including the T-shaped arrow key array. Diamond config, like you have in your mockups, would make me a sad panda.

 

 

As for the SysRq button..

https://en.wikipedia.org/wiki/System_request

 

Basically, it's a special hotkey added for those "Hey, I need a special button not on the keyboard for some radical task!" moments.

 

Like "Turn my TSR's super special awesome mode on/off" kind of thing. 

 

Linux kernel uses it for a magic keypress combo, for instance.

https://en.wikipedia.org/wiki/Magic_SysRq_key

 

People were naturally confused by it, because it has no direct function in and of itself, unlike shift, control, alt, or escape keys. Too bad they put it in such an odd place on the keyboard.

[+mizapf]

1 minute ago, wierd_w said:

Linux kernel uses it for a magic keypress combo, for instance.

https://en.wikipedia.org/wiki/Magic_SysRq_key

 

Raising Elephants Is So Utterly Boring.

[+FarmerPotato]

47 minutes ago, mizapf said:

Why not go for a standard PS/2 keyboard instead of the console keyboard? (I'm living with a Geneve for too long, obviously ... )

 

The point with the cartridge slot is that back in those times when I got the Geneve, I was more than happy not having any of those flaky cartridge ports anymore. Of course, here I could then choose the dump solution and just leave the slots unused.

Lots of options:

 

You can plug a PS/2 keyboard in. A built in keyboard would scan like the  4A keyboard and use the same connector as the 4A keyboard in front. (USB does not seem likely now.)

 

You could take a bare board instead with no keyboard or box, and use your preferred. I could make the box just a box, no console. I just loved making this console. It was important to work out how the I/O ports would fit.

 

The real 4A keyboard connector will go to the I/O processor instead (9995), and support the original keyboard in a 4A case, or a new one. There is a first-layer keyscan on the I/O coprocessor, which forwards data (combined external and internal keypresses!) to a virtual 9901 at >0000 on the main 99105 cpu. (A real 9901 lives at >0400 for interrupt processing.) That gives exact compatibility to GPL mode key scans (as well as in MDOS key functions.) 

 

As for module connectors, I feel like having physical objects is important, and there may be important accessories (FinalGROM is one. How bout Supersketch?) Or that Dragon's Lair must stay in the existing cartridges. Having 3 GROM bases is kind of absurd, but I like it. Its 2 more connectors mostly wired together with extra /GS and /ROMG lines. But I don't know yet what kind of little door would be possible. I don't relish building a spring door. 

 

[+FarmerPotato]

2 hours ago, mizapf said:

Why not go for a standard PS/2 keyboard instead of the console keyboard? (I'm living with a Geneve for too long, obviously ... )

 

Amanda came up with this idea today. It's a bit of laser-cut acrylic, glued onto a keycap.

 

[+FarmerPotato]

7 hours ago, wierd_w said:

I am rather spoiled by the 101 key layout, including the T-shaped arrow key array. Diamond config, like you have in your mockups, would make me a sad panda.

 

 

As for the SysRq button..

https://en.wikipedia.org/wiki/System_request

.

Now I know where SysRq came from.

 

The idea of NMI maps onto SysRq. NMI (or LOAD) is the non-maskable interrupt of the 9900 that typically enters a debugger, or a screen print, or a game cheat. 

The original function on the 990 was to launch a bootloader for the OS.

 

Because all keys are first processed by the I/O co-processor, then sent to the FPGA, implementing "magic keys" will be done in the FPGA, which in turn sends interrupt signals to the CRU or CPU.

 

NMI should be a "magic keypress", if not an outright circuit in itself. (it has its own pin on the CPU.)

 

Similarly, "Turbo" is a magic keypress that changes the GPL speed between emulation and faster speeds. This one should be an ordinary key that causes a state change in the FPGA. The FPGA is in charge of issuing wait states to slow down emulation the actual processor's instructions to 4A speed. Another neat feature there is that the CPU can go at one speed in GPL, but go full speed when it makes a context switch to execute a system call (for instance, when doing I/O in the SD card DSR).

 

I'm interested in adding special keys from TI's 911 VDT terminal. I believe it had a "CMD" key. Because there  is an outside chance that 990 operating systems and languages could run here.

 

 

[+FarmerPotato]

From TI's 911 VDT, video display terminal. It had a controller card that went in the 990 backplane, with one or two CRTs and keyboards.

The CMD key is used to navigate menus in the operating system.

 

 

TI 911 VDT keyboard. CMD key is used in 990 operating system prompts.

Left side arrow pad

Erase    Erase   blank
Field    Input

Print      Up    Repeat

Left      Home   Right

Ins       Down   Del 
Char             Char


    F1 F2  F3 F4  F5 F6 F7 F8 CMD    blank
Caps 1 2 3 4 5 6 7 8 9 0 + - _       Escape
Enter Q W E R T Y U I O P Char Field RETURN
 Ctrl  A S D F G H J K L ; '    TabSkip
  Shift Z X C V B N M , . /   Shift
          SSSPAAAAAAAAACE


Right side

7 8 9
4 5 6
1 2 3
000 +

 

[+FarmerPotato]

7 hours ago, ti99iuc said:

you can also think about the Enterprice64/128

Thanks! I am not familiar with the Enterprise. The joystick on the right I like.

 

[+mizapf]

About my obscure sentence from above...

 

This is a mnemonic phrase to remember a recommended key sequence for SysRq on Linux machines. If the kernel is in trouble and you cannot shut down or reboot anymore, you can use the "Magic SysRq key" (instead of turning off the power or pressing the reset button). This is done by pressing Alt+SysRq+another key, and this last key is:

 

R = stop Raw keyboard mode, go into xlate mode for text mode

E = tErminate all processes (send SIGTERM to all processes except init)

I = kIll all processes (send SIGKILL to all processes except init)

S = Synchronize file system buffers (write buffers to disk)

U = Unmount all writable file systems, remount read-only

B = reBoot imnmediately

 

typed one after another, holding down Alt+SysRq all the time, hence the phrase.

[+9640News]

14 hours ago, FarmerPotato said:

No, not really needed... but it would be fun to have multiple GROM bases.  Ksarul likes the cartridge expander.

 

QUIT was a joke. FN = out to be enough. (keys labeled FN can be purchased but not FCTN)

 

I have no idea what the standard 101-key "SysRq" is for, but I included PrtScn as "Print"

Shift-Print would be the "Turbo" speed control for GPL.

Shift-Break would be NMI (debugger key?)

Reset... maybe that's below the cartridge port? I'm not sure how the Reset will behave--maybe with an on/off button too.

 

This is all playing around.. what are good keys to have?

 

The knobs are for MIDI editing. I want up to 10 knobs, maybe above the keyboard?

 

What do you think, analog joystick or arrow keys? The analog joystick can substitute for a mouse (it's the XBox/Playstation mechanism.)

There is actually a button in the joystick hat, but I threw in two 24mm Japanese mini-arcade buttons.

 

 

I deleted the RGB and DVI ports, and put in VGA and mini-DP. Really anything could happen -- undecided whether video should be 9958 or F18A or both. 9958 RGB could use that connector, if not actually VGA signal. Oh, and I fit in some SD slots. Standard size SD like in FlashROM will be standard media. At least 2 SD slots, one for booting, other for swapping. Unless one of each microSD and SD? That would actually be easier to put on a riser, with microSD below SD.

 

 

You need to support the 9938 as either the 9938 or 9958. If the F18A does not support the entirety of the 9938 features, I would never go down that road as a Geneve system.  
 

Beery

 

[+FarmerPotato]

On 11/25/2019 at 7:44 PM, BeeryMiller said:

 

You need to support the 9938 as either the 9938 or 9958. If the F18A does not support the entirety of the 9938 features, I would never go down that road as a Geneve system.  
 

Beery

 

Yeah, thats true. It takes a real 9958 to be compatible.

So I consider having two connectors for VDP "cards", with a port included on each. You could add a second 9958, or an F18A. I'm going to worry about one 9958 to start with.  (9958 is 9938 plus RGB, plus horiz scroll, minus composite and mouse/light pen. And you can get it easily for $8.)

 

The mechanical problem I tackled with this model: where do the innards go? The sound ports are integrated with the CPU module, so they're on the left. But the right side was the IO processor. I was fixed on the idea of it being near the 4A keyboard and joystick connectors. But removable video in the center means a lot of empty space underneath it? One other way is to put all the IO in the center, and video on the right.

 

Or one long skinny backplane for video and IO. Modules should not waste any space, so simple rectangles that fit together.

 

That would be roughly like this:

 ........ports..................

IOIO  VDP VDP SER AUD

IOIO  #1# #2# RAM CPU

IOIO  VDP VDP RAM CPU

<<<<<<<<<<bus<<< containing high-speed I2C and slow 8-bit VDP

 

up to now I have worked on this layout: 

 

..........ports..........

IOIO VDP SER AUD  (yeah, SER jumped over next to IO later)

IOIO VDP RAM CPU

IOIO VDP RAM CPU

 

 

If it was designed with a backplane, then that could easily be transformed from laying down flat, to vertical connectors, to make a neat little cube. Hmm...

 

The IO card is the only part that is already fully routed on a PCB, I thought to produce that first because it's a 9995 standalone computer on a 3x5 card.

 

 

[+FarmerPotato]

AUDIO recording and playback from BASIC

What follows is a imagining of what an Audio and Speech recording facility might look like in BASIC.

The hardware design so far is a Cirrus  CS4344 DAC, and I've got output working in the FPGA for a 76489 sound chip core. I will probably add the CS5343 ADC chip to do MIC and LINE level input as well.  Cirrus chips are in most laptops.

Why BASIC? Because advanced features should be accessible to everybody. Even if BASIC is not ideal.
But keep in mind, if this is a MDOS basic, it is going to be faster than TI BASIC.
Otherwise, FORTH will be the major supported language. I leave other languages to others...

DSR device names are MIC, LINEIN, LINEOUT

 

Example 1:  Acquire 1 second of audio from the ADC

OPEN #1:"MIC.SF=8.BS=1.TR=8",INPUT,INTERNAL,FIXED 128

* SF=8   Sampling frequency is 8 kHz
* BS=10  DSR gets memory by requesting supervisor to set up a DMA buffer to the ADC. ADC then does direct DMA.)
* TR=8   Trigger recording when input sound level reaches threshold of -8dB. Capture buffer begins to fill then.

* get 128 byte chunks up to 8K
DIM A$(64)
FOR I=1 TO 64
INPUT #1:A$(I)
NEXT I
CLOSE #1

* playback sound
OPEN #2:"LINEOUT.SF=8.BS=1",OUTPUT,INTERNAL,FIXED 128
FOR I=1 TO 64
PRINT #2:A$(I)
NEXT I
CLOSE #2
* Close causes playback to begin

* DSR for a speech encoder built into the OS. I have no idea how I'm going to do this, except, it's been done before and we have BlueWizard source

OPEN #3:"SPCODER.SF=8.BS=1",UPDATE,INTERNAL,FIXED 128
FOR I=1 TO 64
PRINT #3:A$(I)
NEXT I

* encoding starts when input is called. This may take some time!

INPUT #3:LPC$
CLOSE #3

* Speak the result on the TMS5220C
CALL SAY(,LPC$)

 

[HOME AUTOMATION]

I really could have used this around '83...

 

But even now, would be quite welcome!

 

 

  P.S. any thoughts on the V.R. front.

[+FarmerPotato]

3 hours ago, HOME AUTOMATION said:

I really could have used this around '83...

 

But even now, would be quite welcome!

 

 

  P.S. any thoughts on the V.R. front.

Haha.. thats rich.. VR!

 

You mean, like stereo video?

 

Actually, if there are two VDP "slots" (and I am finding this a necessary feature because there has to be a way to fit in a F18A, while not excluding a 9958)

 

With two VDP slots, you could put in two F18As and probably find a supported heads-up display. But good luck getting two F18As

Then you could go ahead and write software for two displays.

 

Does that answer your question?

 

The 9958 still belongs to the era of background graphics + sprites, not to 3D scaled sprites or full motion or massive polygon rendering.. which came closer to 1994.

 

That said, there is this demo for the 9938

 

 

 

Another example

 

 

 

[HOME AUTOMATION]

no, no, no, not Virtual Reality...

 

...VOICE RECOGNITION!

[+FarmerPotato]

I did not ever look into the V9990 chip until now. Here is some info:

https://www.msx.org/wiki/Yamaha_V9990

 

It is not backwards compatible with the 9938/58. For one thing there are no text modes.

It provides higher resolutions, more colors, more sprites in tile mode (but no sprites in bitmap?), and 20x faster block moves.

 

Having crazy thoughts about ... if you wanted to, you could emulate the text modes by using graphics. To make it compatible, this would mean the hardware (FPGA) caches the register state and translates character writes to the screen into "copy character graphic from font" block moves. Crazy...

 

However, V9990 seems to have the same superimpose function as the V9958. So, just maybe it could overlay its graphics onto the V9958 output. 

 

The V9990 is similar to a preliminary spec describing a V9978. V9990 was never used to make a MSX3 computer, but appeared inside cartridges for MSX2 (the home territory of the V9938.)

 

[+FarmerPotato]

6 minutes ago, HOME AUTOMATION said:

no, no, no, not Virtual Reality...

 

...VOICE RECOGNITION!

 

Oh, OK!

 

I don't have any ideas there.

[Nick99]

2 hours ago, FarmerPotato said:

 

If the V9990 could be implemented in some way would be awesome!

[+FarmerPotato]

Adapting MDOS, XOPs, and Interrupts

I did a read-through of the MDOS 6.50 source code and API, looking for code that must change for the TMS99105. It includes rewriting the XOP entry code. But that's ok.

 

First: On the TMS99105, there is Supervisor mode (call it SUPER) and User mode (USER). Geneve2020 will have an 128K EPROM-based kernel that runs as SUPER with a private Static RAM, while MDOS runs as a USER application in main RAM.

 

Second, some TMS99105 instructions can only execute in SUPER. If the USER application tries to execute them, the SUPER takes over and decides what to do. These include LIMI, XOP, and LST; also, all interrupts. Whenever the SUPER takes over, the entire memory map is switched to its private EPROM and RAM.

 

The MDOS APIs are implemented as XOPs.  This means that the XOPs all go over to SUPER, which decides whether to run a new version as SUPER (for instance: memory management), or branch to USER's copy of the XOP (for instance: math). New versions of XOPs, that run as SUPER, are rewritten to access USER memory for registers and data. LIMI 0 will be simulated in SUPER, which continues to get all interrupts first. SUPER checks if the USER application is ready to handle the interrupt now or later.

 

I'm aiming for 100% binary compatibility. To that end, if you boot an existing build of MDOS, the APIs will just work, because all of the XOPs will branch into patches in SUPER code instead of the original MDOS. Unfortunately that means that if you run an older MDOS build, it could get patched to the latest greatest XOP (bug fixes and all.) Oh no?

 

As an additional perk, I foresee having more than one MDOS instance loaded simultaneously, each with its own 2MB slice of memory, and a key to switch between them. 

XOP Flowchart

SUPER runs the USER application

USER application has its XOP table in RAM at >0040

USER application tries an XOP

SUPER takes over, vectors through its XOP table in EPROM

SUPER decides how to handle the XOP

Case 1: SUPER runs a new implementation of the XOP in its EPROM, retrieves registers and data from USER, writes results

Case 2: SUPER branches through the USER XOP table

 

INTERRUPT Flowchart

 

SUPER sets the interrupt mask in the Status Register to take all interrupts (say LIMI 4)

SUPER runs the USER application, marking its application interrupt mask to 2, but not changing the actual Status Register.

Case 1: an INTx comes in (RESET, INT1, INT4, NMI, etc)

TMS99110: SUPER takes over and branches to SUPER INTx vector

Execute any SUPER handling for this interrupt

If USER application mask >= actual INT level, 
    Mark interrupt as handled in USER
    Branch through appropriate USER interrupt vector, but set up USER registers for RTWP back to where USER was interrupted.
    USER does its interrupt routine
    USER RTWP goes back to where USER was interrupted.

Else

    Mark a pending INT in the USER table.
    Return to USER where it was interrupted.

Case 2: USER makes a LIMI call

    SUPER updates the USER interrupt mask, not the actual Status Register.
    If there is a pending interrupt, go to Case 1
    Else return to USER

Benefits

 

 

• Your MDOS disk images can boot and just work
• You could switch between more than one MDOS instance in memory
• If MDOS crashes, the SUPER is still there to help you recover
• MDOS doesn't prevent SUPER from getting important interrupts 

 

 

[+9640News]

On 11/25/2019 at 2:03 PM, FarmerPotato said:

Lots of options:

 

You can plug a PS/2 keyboard in. A built in keyboard would scan like the  4A keyboard and use the same connector as the 4A keyboard in front. (USB does not seem likely now.)

 

You could take a bare board instead with no keyboard or box, and use your preferred. I could make the box just a box, no console. I just loved making this console. It was important to work out how the I/O ports would fit.

 

The real 4A keyboard connector will go to the I/O processor instead (9995), and support the original keyboard in a 4A case, or a new one. There is a first-layer keyscan on the I/O coprocessor, which forwards data (combined external and internal keypresses!) to a virtual 9901 at >0000 on the main 99105 cpu. (A real 9901 lives at >0400 for interrupt processing.) That gives exact compatibility to GPL mode key scans (as well as in MDOS key functions.) 

 

 

I'm not sure using what you describe as the "same connector as the 4A keyboard" is going to be wise.  There is a lot of code in the keyboard XOP' which is intermixed with the video XOP.  The video XOP and keyboard XOP code were tied together, and if memory serves, there was not much memory left.  So, unless your 99105 is going to map both keyboards into the same Geneve keyboard mapping model, there is going to be more rewriting of code.

 

Myself, as others have indicated, the straight 101 keyboard is the preferred direction.  I think trying to go with something less will be crippling to the system.  That's just my take.

 

Beery