Jump to content
IGNORED

Geneve 2020 Questions and Answers!


dhe

Recommended Posts

 
I've been reading the TM 990/10 docs, and it's brought up a number of questions....
 
Have you considered creating a hypervisor layer with an Arduino or pi?
 
One of the nice features of the 990 chassis, was plug and pray - each slot was tied to a specific cru address, so need to set them.
 
Two nice add on's that were made for the 4a, that would be nifty to build in, was Mack Mccormic published a circuit diagram when he was writing an assembly tutorial for Micropendium, that would slow down a 4a, to a craw so you could see what was happening in assembly, by playing with interrupts. The other, also interrupt focused was Jeffery Browns terminal emulator, where you programmed a non-maskable interrupt.
 
When I was using a Genève mostly, I always loaded a little program that was tribute to the Amiga, when an illegal opcode was executed, it had a TSR popup with Guru Meditation Error, that usually mean code had wondered off into some area, that it shouldn't have - like executing data! ? IT would be neat if that situation could be handled by a hypervisor.
 
When you get ready to release cards, maybe we can get Beery's permission to include his HD Image on an SD Card, that could save people years of trying to track down source code and get it transferred.
 
A Geneve is faster than a TI, a GenMod Geneve is faster than a Geneve, where do you think Geneve 2020 will fall on the speed scale if you end up using 6Mhz TMS99105's?
 
 
Link to comment
Share on other sites

12 hours ago, dhe said:

 Hi mizapf, sorry if that wasn't clear, as I really didn't know who wrote it, I remember I got it off 9640 news and always loaded it before a session.

No, nothing to be sorry, I'm happy to hear someone else has been actually using it! ? I had an Amiga in those times as well, and from there I got the idea to make use of the MID interrupt.

 

I always wondered why this feature was disabled in MDOS / GeneveOS. Just a few days ago I noticed that DM-1000 which I was using with the Horizon emulation has a minor bug; it runs over a 0000 at some point. This would have caused a MID with the Geneve, while it would not have been noticed with a TI. So maybe the authors of MDOS considered this to cause more trouble than benefit.

Link to comment
Share on other sites

I consider the program to be very valuable. About the time the Geneve came out, the TI community was experiencing a pandemic of it's own. Corrupt software, either from bad diskettes, poorly aligned drives, bad BBS downloads etc. Many times, these were blamed on the hardware - people would say  'my Geneve keeps locking up'. Guru Meditation PROVED, the Geneve wasn't just 'locking' up, and in fact pointed directly to the problem. I remember at least two cases, where Guru, spurred me on to get new copies of the software, and that ended up being the fix to my 'lock up problems'.

 

So, thank you for the Guru!

 

  • Like 2
Link to comment
Share on other sites

Hey, I welcome suggestions & feature requests! This project originates in imagination. 
 

 

15 hours ago, dhe said:
 
I've been reading the TM 990/10 docs, and it's brought up a number of questions....
 
Have you considered creating a hypervisor layer with an Arduino or pi?


Not clear exactly what you imagined? There will be a supervisor (BIOS) as that's a feature of the 99105. I understand a hypervisor to mean a manager of virtual machine containers, which boggles my mind.

 

Supervisor on the 99105 gets the first look at all interrupts. It has even more decisions to make about INT2 or MID, including dropping into the debugger. I will leave it open to forwarding to MDOS in case you set the INT2 vector there.  
 

Coprocessors are an idea I've imagined. An Arduino, ATMEGA328, is more powerful than a 99105 and doesn't seem fair. I considered a TI '430 but that's in the same class. If there's going to be a co-processor it should be a 9995. Some jobs it might do are: controlling the boot process, serial IO, disk IO.

 

 

 

15 hours ago, dhe said:
One of the nice features of the 990 chassis, was plug and pray - each slot was tied to a specific cru address, so need to set them.

Fixed CRU addresses for devices, too much of a bedrock assumption in our software.  Geneve2020 will make extensive use of byte/word-parallel CRU IO, which will add to the fixed address map! For instance, the video card can respond at memory >8C02 in GPL mode, but CRU >8C02 in BIOS mode.

 

15 hours ago, dhe said:
 
Two nice add on's that were made for the 4a, that would be nifty to build in, was Mack Mccormic published a circuit diagram when he was writing an assembly tutorial for Micropendium, that would slow down a 4a, to a craw so you could see what was happening in assembly, by playing with interrupts. The other, also interrupt focused was Jeffery Browns terminal emulator, where you programmed a non-maskable interrupt.

 

NMI is built-in. Speed control is something I've deferred, as it is a big detail-oriented job. My thinking is that the FPGA will insert wait states to match GPL speeds etc. But how many? It could add a bazillion if you like. A single-stepping debugger is a possibility--TI describes how to use NMI for single-stepping, in the University Board 990/189 coursebook/manual. Probably some other places too.

 

I'm thinking of a way to make low-level patches easy. BIOS will accept a startup script, written in FORTH (which includes the assembler). In there, you can add pretty much anything you think of. This script would typically just say BOOT-MDOS, but the possibilities are wide open. It could change the NMI behavior for instance.

 

16 hours ago, dhe said:
A Geneve is faster than a TI, a GenMod Geneve is faster than a Geneve, where do you think Geneve 2020 will fall on the speed scale if you end up using 6Mhz TMS99105's?
 

It will be faster :)

 

You could look at Stuart's Breadboard benchmarks for one. 

 

Keep the ideas coming!

 

 

  • Like 1
Link to comment
Share on other sites

11 hours ago, dhe said:

Our very own Beery Miller published an action packed Disk-O-Zine called 9640 News. A bit like Genial Travler - except for the Geneve.

 

Maybe if we ask him nicely he will release all the goodness!

All of 9640News was released to the public domain some 15 to 20 years ago.  


It is available for download at several locations:

 

Index of /Geneve/9640 News disks v1-3/9640 NEWS disks for Geneve (whtech.com)

 

9640 News | Jedimatt42

 

 

 

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Sorry, I do not know enough technical details about the Geneve to see if this is feasible or not.

But what would absolutely be great is, if interrupts could be bound to high-resolution (non-maskable?) timers.

Would make reliable multitasking a lot more feasible.

 

Obviously would require OS modifications for supporting all this. But with the source code being available....

Link to comment
Share on other sites

 

GPL Questions:

 

 

One of the mill stones MyARC had hanging about their neck, was being able to run module software.

   Their first decision was no plug in for module, they had Peter Hoddie, write C-Save.

 

 Issue 1, C-Save didn't know how to save all modules.

 Issue 2, Not all modules worked on the Geneve. I remember Mike Maksimik spent a lot of time making modules work.

              Broadly speaking problems seemed to fall in to four large categories.

              a) Bad hygiene on VDP register setup, things you got away with on the TMS9918, no longer did

                        you get away with 96k of RAM and much more complicated V9938 with more registers.

              b) Modules that either played fast and loose with the KSCAN routine, or tried to directly access the keyboard and joysticks via CRU.

              c) Direct access to I/O devices like the sound chip.

              d) Loose programming that worked on the 4A, because the 256 bytes of scratch pad RAM would roll over.

 

 Then you often times had module files, and you thought, is this the FIXED moon patrol from Mike, or just an original dump of Moon Patrol?  There never was a good database of patches or fixed modules put together. (Still isn't).

 

   Two other questions for the architect....

 

    I never saw from Myarc, what the maximum Grom banks that could be used.

    I also never clearly understood, if the Geneve could support modules with RAM memory like

       SuperSpace, SuperSpace II or Minimum.

    Also, Myarc promised P-Code compatibility, I heard rumors of a pcode file but never saw it.

         Now, this could have been for two reasons (or more) - their Grom Operation couldn't emulate a

         P-Card, the Geneve's hardware wasn't compatible with a p-card. Maybe someone got it to run and all the disk-based utility had problems, not unlike some of the modules, or faster term, etc.

 

         In Candyland, I'd like to have full emulation of the P-Code card, and maybe emulation of the SNUG HSGPL card.

 

 

 

 

 

image.thumb.png.e2b2443c228af9a0d8fdcff92c11441f.png

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, dhe said:

 

 

         Now, this could have been for two reasons (or more) - their Grom Operation couldn't emulate a

         P-Card, the Geneve's hardware wasn't compatible with a p-card. Maybe someone got it to run and all the disk-based utility had problems, not unlike some of the modules, or faster term, etc.

 

         In Candyland, I'd like to have full emulation of the P-Code card, and maybe emulation of the SNUG HSGPL card.

 

I was playing (briefly) with the PSYSTEM and I thought the PSYSTEM may be running as it should.  Now, as far as compatibility with P-Code, no idea.

 

As far as the SNUG HSGPL card, seriously doubt any separate card for Groms is going to work as things were hardwired in the gate array I think would prevent that.

 

As far as having 8K ram space at >6000 to >7FFF, that is already there.  You can load the Editor/Assembler module and you have the 8K of memory there already.

 

Beery

Link to comment
Share on other sites

On 11/23/2020 at 5:10 PM, dhe said:

 

GPL Questions:

 

 

One of the mill stones MyARC had hanging about their neck, was being able to run module software.

   Their first decision was no plug in for module, they had Peter Hoddie, write C-Save.

 

 Issue 1, C-Save didn't know how to save all modules. 

 

 Then you often times had module files, and you thought, is this the FIXED moon patrol from Mike, or just an original dump of Moon Patrol?  There never was a good database of patches or fixed modules put together. (Still isn't).

 

 

Well, as far as what Geneve2020 will do with GPL, I really only have vague ideas about it. Working on GPL seems so remote when I'm working on getting the ROMs to boot!

 

Some ideas:

 

Through a "compatibility card", support actual GROM chips or at least copies. An actual cartridge interface , like a card reader on a ribbon cable. (the backplane has 4 or 8 slots, 3 of which are used.) That hardware is just pie in the sky at this point though. Module dump files will be the norm.

 

Standalone GPL, no need why it has to run under MDOS. This is easier in some ways because MDOS does some hacky things with memory pages for GPL.

Also if GPL gets its own memory slice (up to 2MB) it can have SAMS memory.

 

GPL under MDOS is still a goal--that just comes with supporting MDOS memory scheme. But boot to a totally separate GPL is easier to make, in a lot of ways.

 

Quote

I never saw from Myarc, what the maximum Grom banks that could be used.

    I also never clearly understood, if the Geneve could support modules with RAM memory like

       SuperSpace, SuperSpace II or Minimum.

    Also, Myarc promised P-Code compatibility, I heard rumors of a pcode file but never saw it.

         Now, this could have been for two reasons (or more) - their Grom Operation couldn't emulate a

         P-Card, the Geneve's hardware wasn't compatible with a p-card. Maybe someone got it to run and all the disk-based utility had problems, not unlike some of the modules, or faster term, etc.

 

         In Candyland, I'd like to have full emulation of the P-Code card, and maybe emulation of the SNUG HSGPL card.

 

I really have not thought about any of that. 

 

Bank switched modules like XB use a special pair of page#s. I've not heard of Mini Memory implemented. My memory mapper is 4K pages at the core, as TI intended, so I think I can make Mini Memory 4K RAM 4K ROM by clearing the ReadOnly bit on half.

 

I think Myarc had somebody do a software USCD Pascal. Never officially released. No Pcode card involved.

 

Pcode is pretty far out.

 

 

 

Quote

 

Issue 2, Not all modules worked on the Geneve. I remember Mike Maksimik spent a lot of time making modules work.

              Broadly speaking problems seemed to fall in to four large categories.

              a) Bad hygiene on VDP register setup, things you got away with on the TMS9918, no longer did

                        you get away with 96k of RAM and much more complicated V9938 with more registers.

              b) Modules that either played fast and loose with the KSCAN routine, or tried to directly access the keyboard and joysticks via CRU.

              c) Direct access to I/O devices like the sound chip.

              d) Loose programming that worked on the 4A, because the 256 bytes of scratch pad RAM would roll over.

 

This will still be an issue, of patched versions needed.

 

a) VDP Register hygiene. I might be able to help with this, its a long shot. I believe the video card is going to cache all VDP register writes as they go on chip. This enables rapid context switching (putting MDOS in the "background" while a debugger takes over the screen, then switching it back). At least, you could look at what registers changed, and diagnose bad software hygiene. At a stretch, I could make some feature that intervened when a pure GPL program tries to write to regs #8 and up. Like, it GPL hygiene bit is enabled, cause a page fault when VR#8 or above is written. You then approve deny or ignore all such writes, kind of like when Windows asks you if you want a program to be able to write to a file. Or you just run it with writes to VR#8+ ignored (which would disable certain 80-column features like blinky text, or programs that use more than 16K of the VRAM.)

 

b) KSCAN. I have spent way too much time solving this! It was fun.

 

So many things are solved neatly by including a second 9901 chip for GPL to read from. 

 

This will be a 9901 at >0000, dedicated to the MDOS/GPL emulation. Programs that directly read bits from the CRU will see real hardware inputs there. For joysticks that's already what MDOS does.

 

As for how this enables them to see the PS/2 keyboard in KSCAN? When the OS gets a keypress, it has to at least put it into the MDOS register at >F110. So.. it can do lots of other processing. One job is a  lookup table for what CRU bits map to that key on the 4A keyboard, and to load those into a hardware register for GPL to read.  (The 4A has 3 row output selectors to address 8 8-bit read locations.) It is a complicated table--eg pressing ? on the PS2 keyboard is Shift Slash, but ? on the 4A is FCTN I.

 

So when ? is the actual character, it ORs the bits for FCTN + I to the 4A register.  This will, unavoidable, produce a lot of phantom keys (use ? for player 2 up direction I...) Worse, pressing UP-ARROW EQUAL will execute FCTN SHIFT QUIT. Its not perfect but it is great for playing games that scan for player keys. Just don't push UP-ARROW EQUAL.  SHIFT SINGLE-QUOTE produces FCTN P, and so on. Pretty much, be careful never to touch the = key and anything else when in GPL... maybe that needs to be a special case exception, huh.

 

And one more thing... because the 9901 has all the keyboard input/outputs and an external register, it is designed to have you connect a physical 4A keyboard that overrides the register. There is a connector right next to the joysticks for it. It shares the same circuit as the joysticks require. 

 

 

MDOS/GPL and Interrupts

 

4A has INT1 VDP,   INT2 P-Box interrupt  Both call the INT1 handler in GPL because the 9900 interrupt level input is hardwired at 1 (Why???)

 

GPL will see its interrupt level 1 or 2 flags. The "real" 9901 actually takes INT4 for peripherals, but sets bit 1 for GPL to see.

 

 

That is:

 

Real 9901 at CRU >2000 gets INT1 in at >2002

BIOS executes VDP interrupt handler

BIOS sets INT1 bit at CRU >0002

BIOS branches to GPL or MDOS VDP interrupt.

(not perfect yet but I believe it's workable)

 

Real 9901 at CRU >2000 gets INT4 (peripheral) in at >2008 or INT7 (keyboard) at >200E etc.

BIOS executes appropriate interrupt handler

BIOS sets INT2 bit at CRU >0004 for all other GPL interrupts. Or INT7 at >000E (MDOS keyboard interrupt)

BIOS branches to GPL or MDOS VDP interrupt handler for INT1 or INT7 or whatever.

 

 

etc

 

c) Sound chips. I need someone to survey WHAT software has poor hygiene around 8400. Like, writing sloppily to >8500 or >8432 that just work on the 4A. I will be mapping sound to just >8400 to >841E.

VDP, GROM etc are similarly narrowed down. 

 

d) PAD hygiene. Addresses rolling over, I think will be a problem. I assumed there was a page of RAM at >8000-9FFE. So PAD hits that from 8000 to 83FE. 1K of RAM. Except for the memory mapped ports, well, the default behavior is to see RAM at the addresses in between.  I really haven't gotten around to thinking that through--I warned you this was vague...

 

There are undoubtedly going to be problems with software. I will need others' creativity and intelligence to find those.  But, hasn't that been tried on the Geneve 9640? 

 

Finally, I think I can make a GPL that is more compatible than MDOS was.  It is certainly a necessity to have KSCAN working (by that I mean also other people's direct key scanning) because there are so many games that directly scan. Or check for FCTN QUIT or FCTN BREAK alone.  Geneve 9640 GPL couldn't do that.

 

 

 

 

 

  • Like 6
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...