Classic99 Updates

[Tursi]

5 hours ago, jedimatt42 said:

Nothing I've produced would exist without this debugger.

Thanks, and the truth is, nor I. It's at the point where I hate developing on other retro systems because the debuggers are just awkward. At the barest minimum, I make heavy use of the real-time memory view quite a lot, and I haven't seen that anywhere else.

 

The debugger was one of the features that did push 4.x dev, because I really want to be able to break it up and improve the function. The new architecture is based from the ground up to have component-level debug available... although I haven't worked out exactly what that looks like yet. But having the API in place forces me to think about it for every component.  (The biggest issue at the moment is that splitting the debug system up like that is making breakpoint implementation very painful... but it's easier to fix something than build it, so building first, then we'll see if it works!)

 

A downside of using Allegro... or any cross platform toolkit... is that things like extra windows is made more complicated. I've toyed with the idea of the debugger being a separate app that just reaches into Classic99 to get the data it wants. But if I did that, it's likely only Windows would get a debugger... anyway, I'll figure something out.

 

The other thing was just the slew of new hardware that I want to emulate so it can be developed for... it was making things rather awkward in many places of the code. Classic99, nee Ami99, was designed to run a basic simulation of the bare console with 32k and maybe a disk drive that knew how to load PROGRAM images. That's a reasonably stable base, but it's really top heavy now.

 

[Tursi]

Just a quick update - Classic99v4 running natively on Linux. I compiled for Debian 10 using the Allegro5 package from apt, and this is an exe... but you can also pull the project and build with cmake.

 

 

https://raw.githubusercontent.com/tursilion/Classic99v4/master/dist/classic99v4.tgz

 

No feature updates of course. V4 will need a long time before it's useful. But it shows that it works.

 

Allegro is supposed to build for Mac too, so I may well attempt that build as well...

 

[+OLD CS1]

7 minutes ago, Tursi said:

Classic99v4 running natively on Linux.

This just might be the earth-shattering kaboom of a lot of heads popping in excitement.

[+Torrax]

My wish list for Classic99v4 is support for the MBX banking scheme along with Super Space cru banking (up to 128K). As most of the MBX carts will work without the MBX system (2-3 excluded).  Just add support further down the line in the development cycle for the full MBX expansion system.

 

It would be nice to have support for all the different existing cartridge types/banking schemes on the TI-99/4A available with Classic99.

 

Much thanks for all your support and development...

[Tursi]

44 minutes ago, Torrax said:

My wish list for Classic99v4 is support for the MBX banking scheme along with Super Space cru banking (up to 128K). As most of the MBX carts will work without the MBX system (2-3 excluded).  Just add support further down the line in the development cycle for the full MBX expansion system.

 

It would be nice to have support for all the different existing cartridge types/banking schemes on the TI-99/4A available with Classic99.

 

Much thanks for all your support and development...

As usual, I respond to select wishes by traveling back in time and implementing them retro-actively in advance.

 

MBX banking was added 30 Jun 2012, and Super Space CRU banking was added 5 Apr 2009. But to be evil about it, as is my new thing, I only did 64k of Super Space. They are not implemented as separate banking types, though, map Super Space as type '9' and MBX as type '!'. map them as type 9. I haven't tested them for a while, but they should still work - except for software that also writes to ROM, since that will also cause a page switch. I know Red Baron CRU didn't work, and I am not sure which MBX carts I tested, but I remember it working.

 

The CRU paging was how I ported TI Workshop

 

Edited December 27, 2021 by Tursi

[+arcadeshopper]

As usual, I respond to select wishes by traveling back in time and implementing them retro-actively in advance.
 
MBX banking was added 30 Jun 2012, and Super Space CRU banking was added 5 Apr 2009. But to be evil about it, as is my new thing, I only did 64k of Super Space. They are not implemented as separate banking types, though, map them as type 9. I haven't tested them for a while, but they should still work - except for software that also writes to ROM, since that will also cause a page switch. I know Red Baron CRU didn't work, and I am not sure which MBX carts I tested, but I remember it working.
 

Rtfm sigh

Sent from my Pixel 6 Pro using Tapatalk

[Tursi]

Come now, you have to think 4-dimensionally. It does no good to read the manual before I go back in time and update it.

 

Actually... I'm not sure I actually did update it...

 

Hmm.. sorta yes, sorta no. Seems I implemented MBX as type "!", and the manual still doesn't have '9' in the reference section, even though '3' is obsolete. hehe.

 

[+Torrax]

Never noticed the change of '3' supporting SS-CRU switching along with non-inverted ROMs.  Just checked the 30-Jun-2012 manual and see the SS-CRU mentioned but no MBX back then.

 

Okay type 8 are ordered as 0-1-2-3-4-5-6-7 (378); non-inverted.  Which makes type 9 ordered as 7-6-5-4-3-2-1-0 (379); inverteded.  Your description in the docs indicate type 3 as 0-1-...... and using the 379 decoder.  Right??  The description of type 3 comes across as confussing in figuring out the proper ordering of the banks.

 

Should the description for type 3 be re-written as follows:

 

Packed banks with a '379 style decoder. Similar to XB style but more banks and all in one file. Note that this assumes a load at >6000, so you are specifying
the offset in the banking space, with bank 1 at >0000, bank 0 at >2000, etc. SuperSpace carts (CRU >400) can be loaded this way for now, too, but will
likely split them up later. Max size is 32MB, although SuperSpace is limited to
accessing 64k.

 

Or do I have the ordering all wrong and backwards.

 

Haven't done any projects larger than two banks and want to get the ordering right.

 

[Tursi]

4 hours ago, Torrax said:

Never noticed the change of '3' supporting SS-CRU switching along with non-inverted ROMs.  Just checked the 30-Jun-2012 manual and see the SS-CRU mentioned but no MBX back then.

 

Okay type 8 are ordered as 0-1-2-3-4-5-6-7 (378); non-inverted.  Which makes type 9 ordered as 7-6-5-4-3-2-1-0 (379); inverteded.  Your description in the docs indicate type 3 as 0-1-...... and using the 379 decoder.  Right??  The description of type 3 comes across as confussing in figuring out the proper ordering of the banks.

 

Should the description for type 3 be re-written as follows:

 

Packed banks with a '379 style decoder. Similar to XB style but more banks and all in one file. Note that this assumes a load at >6000, so you are specifying
the offset in the banking space, with bank 1 at >0000, bank 0 at >2000, etc. SuperSpace carts (CRU >400) can be loaded this way for now, too, but will
likely split them up later. Max size is 32MB, although SuperSpace is limited to
accessing 64k.

 

Or do I have the ordering all wrong and backwards.

 

Haven't done any projects larger than two banks and want to get the ordering right.

 

Manuals are a lot of work, and when I finally got something working at 8:30am with an 11am meeting, I didn't always remember to update the manual before bed. Besides, the main response to the manual has been "it's not good enough". Much like you're doing here.  Seriously, I could have saved myself a ton of work and abuse and not done any of it, and likely not impacted the amount of needed support. All it did was create yet another thing I needed to update. There won't be a v4 manual.

 

Read whatsnew.txt instead for feature changes, that's where I got the dates from.

 

The 3, 8, and 9 tags were taken from the use of the 74LS379 to make new cartridges. I chose '3' for "379" as the new V9T9-style tag. The 379 design used inverting outputs, which caused the order of the banks to be inverted from what one might expect.

 

Later, larger cartridges were designed using the 74LS378. These were non-inverted outputs, leading to the "non-inverted" bank layout in the ROMs. At this time I realized the choice of '3' was dumb, and changed it to '9', then added '8' for the new one.

 

The description you are reading predates the 74LS378 carts, so there was little incentive to be detailed about the bank order - there was only one standard at the time.

 

The thing is, the MBX ROMs that I have are /already/ in the correct banking order. Unless you are making your own dumps, you shouldn't have to worry about it. If you are, then just drop them in the image assuming inverted address lines on the latch (which means that the bank selected by latch address 0 goes at the END of the EPROM -- what that means wrt the RAM I don't recall).

 

Actually, scratch all that advice. I've no idea what the banking order for the MBX ROMs are. The SuperSpace ROMs appear to be in inverted order, but I'd have to look at the code for MBX.

 

Which I've done... MBX carts have the lower 4k fixed, with 3k of ROM and 1k of RAM. The upper 4k is banked via writes to >6FFE, and the data bus is latched. They seem to be non-inverted bank order, but I have comments that I still needed to investigate the actual ROM dumps and understand the layout (including "Why does this work?", which is always encouraging... )

 

 

Edited December 27, 2021 by Tursi

[+Torrax]

Thanks for the clarification and continued support of Classic99.  I'll try out my MBX dumps (CYC) while staying warm this week.

 

Enjoy the cold snap up here in YYC

[mr_gw454]

On 12/26/2021 at 6:53 PM, Tursi said:

Just a quick update - Classic99v4 running natively on Linux. I compiled for Debian 10 using the Allegro5 package from apt, and this is an exe... but you can also pull the project and build with cmake.

 

Hi Tursi,

 

This worked perfectly after installing the Allegro 5 libraries.  Never thought I'd see a native port of Classic99 for Linux.  Thanks so much starting down this road...

 

 

[Tursi]

I do! It's still pretty novel!

 

Anyway, unrelated to that, here's V4 running natively in Mac OSX. However, it's really unstable, and I am not sure why. Just getting it to build was an interesting challenge, as I've not done Mac code before, so I've got some learning there. But it appears the Mac version of Allegro also has some special gotchas. If the app starts without bombing, it's pretty stable, but touching the window is taking my life into my own hands (or at least, risking a segfault). Possibly I've initialized something incorrectly, maybe there's a race inside Allegro. More time is required. But in the meantime, this proves at a basic level that it can work... I was able to get into Demonstration and music and keyboard were both fine.

 

[Tursi]

3 minutes ago, mr_gw454 said:

Hi Tursi,

This worked perfectly after installing the Allegro 5 libraries.  Never thought I'd see a native port of Classic99 for Linux.  Thanks so much starting down this road...

Good to know, you never know if things will work for anyone else. Long way to go, but yeah, once I get the build systems nailed down making alternate targets will be fine.

 

It's interesting to note that Ami99, Classic99's older name, had a native Linux port as well. This was also possible because it was built on Allegro (DOS version back then), but it was maintained by someone else. Eventually we fell out of contact and when I moved to Windows I stopped using Allegro, breaking the portability.

 

[jrhodes]

On 5/9/2021 at 8:46 AM, jrhodes said:

@PeteE & @Tursi, who ever releases first, i won't tease/bug/pester for at least 6 months. ?

 

@Tursi, @PeteE, remember when i said this? I know i remember it!

Sure its "unusable", but Tursi has a v4 of his Classic99 now ?.

Looks like i get to bug the snot out of PeteE for a while .

[Airshack]

On 12/23/2021 at 8:12 PM, Tursi said:

The other thing was just the slew of new hardware that I want to emulate so it can be developed for...

MBX emulation is perhaps too much to wish for?

[Tursi]

12 hours ago, Airshack said:

MBX emulation is perhaps too much to wish for?

It becomes feasible in the distant V4 future, but the likelihood is low. I don't plan to write any software for the MBX and I don't see any other active projects.

 

If you just want to /play/ MBX, that's more a MAME thing (plus I believe MAME already has the needed CPU and speech chips emulated )... not that this is a small task even then since there's also unique hardware and the need to communicate with the TI in an unusual manner.

 

Edited December 29, 2021 by Tursi

[+mizapf]

We're talking about the MBX console, I guess (not just MBX-like cartridge space). I have one here, but I did not yet have a look inside ... too many open projects.

[+OLD CS1]

How might one go about emulating both the MBX console keypad and the TI keyboard simultaneously?

[Retrospect]

57 minutes ago, OLD CS1 said:

How might one go about emulating both the MBX console keypad and the TI keyboard simultaneously?

You can't.

[jrhodes]

3 hours ago, OLD CS1 said:

How might one go about emulating both the MBX console keypad and the TI keyboard simultaneously?

 

2 hours ago, Retrospect said:

You can't.

Display the keypad in a popup window that has the required overlay pictured on it. Click the button on the virtual keypad to interface with it.

[Retrospect]

36 minutes ago, jrhodes said:

 

Display the keypad in a popup window that has the required overlay pictured on it. Click the button on the virtual keypad to interface with it.

I thought that at first, but the word "simultaneously" threw me.  

[+OLD CS1]

1 hour ago, Retrospect said:

I thought that at first, but the word "simultaneously" threw me.  

Yup.  Words have meaning.  Though, for complete fairness, I am not aware of any game which uses both the TI keyboard and MBX keypad simultaneously.

[Tursi]

8 hours ago, Retrospect said:

You can't.

Well, there are enough keys on a modern PC keyboard, 48 keys for the TI. How many on the MBX? Probably less than 53!

 

The trick with the MBX is it's a second computer, so you need to implement a whole second architecture.

 

IIRC, the communication is via the joystick port, was it? So emulation will need to account for the joystick port also being a communication device.

 

Anyway, Classic99 is a development tool. Unless I have a reason to be writing MBX software, it's unlikely. There's already tons of hardware I need to support

 

[Retrospect]

8 hours ago, Tursi said:

the communication is via the joystick port, was it?

yeah i think it was.  When i said "you can't" it was due to my being confused with the simultaneously statement, already in my mind was a pop-up window with the MBX stuff aside the Classic99 window.  One way I suppose it could be done if you ever did it, would be to make use of a second keyboard (should the need arise if the user doesn't have a full keyboard say on a small laptop) .... can classic99 detect a USB keyboard being plugged in at all?  I wouldn't have a clue!  But it could be handy and nifty.  Overall though I do agree with you, it might be a stretch too far considering classic99 is a dev tool. 

[+mizapf]

If I tried to do it in MAME, one could probably map the number keypad to the MBX keyboard. There is the "Input (this machine)" option in the OSD menu where you can freely map real keys to emulated keys. This may not be enough, so probably adding the cursor keys and the Ins/Del block could do it.

 

From the general concept, even with the device having an own processor, speech chip etc., it should be doable. But as I said, I can only do one thing at a time, and the SCSI emulation seems to make more sense right now.