Classic99 Updates

[Tursi]

2 hours ago, mizapf said:

I'm tired about discussing operating systems. I know which one is best for me.

And so do I, and I noted that I /did/ want to talk about it. But you did more work to not participate than actually not participating would have taken.

 

 

[GDMike]

Well, no matter what operating system anyone chooses I think I'm kind of worried about how and where it's going to boot to and from, and more importantly where is all my data going? So instead of looking for viruses on your hard drive and preventing them let's just open everything up for the world to see without you even having a chance to guard it.

Edited May 10, 2023 by GDMike

[+arcadeshopper]

 

[+OLD CS1]

3 hours ago, mizapf said:

I'm tired about discussing operating systems. I know which one is best for me.

Me, too.

 

 

7 hours ago, RXB said:

Yea well Microsoft has never had a original idea ever, it copied Unix OS X and copies Linux concepts.

Not completely fair.  Microsoft created Microsoft Bob.  What Microsoft seems to excel at is taking existing products and making them, arguably, better or more functional.  Pretty much everything in its portfolio of success is an acquisition, or a "better mouse trap," so to speak, rendition of a previously existing product.

 

4 hours ago, Tursi said:

Microsoft developed the Start button that everyone else copied.

It is funny to think of how many OSes I have touched which incorporated a kind-of Start button.  My favorite was Sun's Java Desktop, but there are also similar launchers in just about every Unix/Linux GUI I used back-in-the-day, even my beloved Amiga. The idea of the Start button and Start Menu really was radical, and so useful, or comfortable, Windows users revolt any time Microsoft makes a change to it.

 

At some point someone is going to chime in and say "they all stole it from Xerox PARC," which is a (Microsoft|Apple)-hating revision of history.  Xerox and those involved in PARC habe said numerous times they invited the nerds of the day to come and look at what had been developed at PARC.  Xerox seemed to have no interest in making commercial products of what they had developed in-house.  In the 1970s, thousands of said nerds visited PARC and saw the same things Gates and Jobs saw.  While Apple had a special relationship with Xerox and its people were allowed to see the advanced stuff not open to the public, they left with nothing in hand and only with what they had seen dancing in their heads like visions of sugar plums.

[RXB]

Getting back to the TI99/4A....again...

 

I would have liked to select what device Floppy or Hard Drive or TIPI to boot from and the CARTRIDGE it would use in a menu.

Seems a pain to first select Cartridge then from there select which drive to boot, not just default to drive 1.

 

Again why I loved the SOB that did all of this for you. It made the TI99/4A more modern with a menu or Drives and Carts.

[+OLD CS1]

4 hours ago, arcadeshopper said:

 

[HOME AUTOMATION]

6 hours ago, arcadeshopper said:

🔭

[jenorton]

Goodmorning/afternoon, or whatever <grin>

 

I am about to pull my hair out--I look like I've been through a heavy session of chemotherapy already!

 

Just so this topic isn't cluttered, feel free to reply to me at 

 

joseph dot norton (at) gmail.com (sub the punctuation and take out the spaces).

 

Tursi, if you want, you can weigh in on this, but, I am ok with any suggestions.

 

I can get the source of Classic99 from Github, easy as pie.  It looks like I can go to the Micro$oft Web site and download Visual Studio from 2013 to the present.

 

However, nothing I download is allowing me to build my own copy.  One thing or another seems to be missing.

 

I just want to build my own copy, play with the code, maybe mess it up, blow it away and do it all over again.

 

Can I still do this starting from scratch, or are some of the build tools not available anymore?

 

Pleeeze, help me not to go bald on this.  (I secretly want to be bald, if I don't have any other problems, but, my family doesn't want me to be bald, especially my wife).

 

Thanks for any help.

[Tursi]

With apologies, I pulled it down myself and had no luck at all. 

 

It's a Visual Studio 2017 XP targeted project, though today I build under 2019. I don't know if 2013 can work. Even so, I have hard coded references to the Direct-X SDK in the project settings (for CartPack and Classic99 each). So to build as-is, you need the XP build support installed, and you need a compatible Direct X SDK.Again, the Platform Toolset is Visual Studio 2017 - Windows XP (v141_xp), which I believe requires an extra install, and the DirectX SDK is June 2010. There are also two hard coded paths in the Executables path (For Visual Studio 10 and NASM) - I don't think those are still needed. (NASM was only ever needed for the HQ4X filter anyway. Classic99 runs fine without the filters.)

 

Attempting to upgrade the project gave me all kinds of path problems, unable to find basics like Windows.h. Resolving one just popped up another and it probably needs a true update for that to work. It's possible that the project has been upgraded so many times, and probably started life so rough (I started this in Visual C++ 5.0), that it might not be possible to get a clean update. Probably the solution needs to be blown away and set up from scratch.

 

Sorry, I know that's not the answer you're after. But if you can grab 2017, install the XP 141 toolset, and the June 2010 DirectX SDK, it probably will build (after updating the SDK paths). For any other combination that's untested.

 

[jenorton]

Hi:

 

No problem.  I just hope you didn't mess anything up on your end.

 

Those clues are quite useful.

 

Again, I hope this didn't mess anything up on your end.

 

Thanks!

[jenorton]

Oh, I've got another project underway.

 

I have CADD's PC99W suite, and, I'm in the process of setting up Classic99 with carts from WHTech in the same order as they appear in PC99W's list.

 

I came across one called "Amateurfunk" from "Hagenbuk".  It came in 2 files, FUNK1.GRM and FUNK2.GRM.  Just to see what would happen, I copied them over, changed them to .bin files, removed the first 6 bytes, so both files were 8,192 bytes long, and, took a chance, and named FUNK1.BIN to FUNK1G.BIN and FUNK2.BIN to FUNK2D.BIN.

 

I selected it, and, looks like it works.

 

I got the menu:

 

    PRESS                       
                                
    1 FOR TI BASIC              
                                
    2 FOR AMATEURFUNK 1         
 

I selected 2 and it looks like a cart for figuring antenna lengths or wavelengths.

 

So, did I luck up on the right names?  Would it still work if I changed one of them?

 

I'm assuming if things weren't right, it wouldn't come up.

 

Thanks!

[+mizapf]

"Funk" in German is "radio" in English, so "amateur radio". ("u" like in "put", the word actually translates to "spark", which is from the early times when Hertz and Marconi used sparks to transmit signals. Not to be mixed up with English "funk".)

[jenorton]

Hi Michael:

You confirmed what I surmised from the menus.  Looks like an sort-of toolbox for Ham Radio stuff.

This thing even has a morse code mode, you can either give it text or it has a keyboard mode that it outputs code when you type a character.  Probably other settings for speed and such.

At the bottom of the main menu, it says "(C) K.HAGENBUCHNER    1985"

 

In CADD's configure program where you select a module, you can copy the info for a module to clipboard.

Here's what this one looks like:

 

amateurfunk (hagenbuch)
\CADD\MODULES\HAGENBUC\FUNK1.GRM    FF 04 20 00 60 00     GRM 3
\CADD\MODULES\HAGENBUC\FUNK2.GRM    00 05 20 00 80 00     GRM 4

Just for comparison, here's the info for Tursi's example, Pole Position:

 

pole position (atari)
\CADD\MODULES\ATARI\POLEPOS.GRM    FF 0A 20 00 60 00     ROM 1
\CADD\MODULES\ATARI\POLEPOS1.GRM    00 09 20 00 60 00     ROM 0

In my experimentation, I noticed the second file in AmateurFunk (funk2.grm) seems to have a load address of 8000, if I read the info right.  I did 2 things, both of which seemed to work:

first, I combined the 2 files, copying the first file and adding the second to it, stripping off the 6 byte header for both, making the single file 16,384 bytes.  I called it "funkg.bin" and Classic99 loaded it with no problem, from what I can tell.  

I also added it to the .ini file like this, keeping the 2 8,192 byte files separate:

[Groupa10]
name="AmateurFunk"
ROM0=G|6000|2000|mods\funk1g.bin
ROM1=X|8000|2000|mods\funk2d.bin

It didn't seem to care if I used 8000 or 6000 for the second file, but, I saw that in the clipboard output, so I tried 8000.

Is the TI really forgiving? It would seem if I got any number wrong, I wouldn't get anywhere.

I'm shooting in the dark--which I'm used to anyway.

Neat stuff, though.

[+mizapf]

2 hours ago, jenorton said:

At the bottom of the main menu, it says "(C) K.HAGENBUCHNER    1985"

If I remember correctly this is one of our Austrian friends, @kl99?

[Tursi]

When using the INI file, the filename is irrelevant, but the "D.BIN" extension is meant to indicate the second half of a 16-k ROM like Extended BASIC. This is also so for the 'X' in the INI. X and C type can only load from 6000 to 8000, so starting an 'X' type at 8000 will make nothing from the ROM load at all. Classic99 knows its memory spaces and won't load files load outside of them. 

 

That said -- those six bytes do have meaning. What I am seeing there is further hinted at by the GRM3 and GRM4 hints.

 

The first byte, FF or 00, indicates if there are more files to load. (00 means last file).

The second byte identifies the type of memory - that's how your tool is recognizing GRM or ROM.

The next two bytes are the length - 2000 hex in all your samples.

The last two bytes are the load address. GRM3 loads at 6000 hex, and GRM4 loads at 8000 hex, which we see there.

 

So what this means, is you have two GRM files, representing the two separate chips (instead of the larger combined file we often see these days). Classic99 won't auto-load that, but in your INI, change the type of the second file back to G, and leave the 8000 load address, and it should work. Likely there are parts of the program missing without that - but it will still show up and launch because the header is in the 6000 GROM.

 

Files set up in the Classic99 INI will recognize and skip that 6 byte header automatically if and only if the first byte is 00 or FF, and the fifth and sixth bytes exactly match the load address in the INI. It doesn't try to parse the data beyond that, relying on what the INI says instead.

 

[jenorton]

On 5/13/2023 at 11:59 AM, Tursi said:

When using the INI file, the filename is irrelevant, but the "D.BIN" extension is meant to indicate the second half of a 16-k ROM like Extended BASIC. This is also so for the 'X' in the INI. X and C type can only load from 6000 to 8000, so starting an 'X' type at 8000 will make nothing from the ROM load at all. Classic99 knows its memory spaces and won't load files load outside of them. 

 

That said -- those six bytes do have meaning. What I am seeing there is further hinted at by the GRM3 and GRM4 hints.

 

The first byte, FF or 00, indicates if there are more files to load. (00 means last file).

The second byte identifies the type of memory - that's how your tool is recognizing GRM or ROM.

The next two bytes are the length - 2000 hex in all your samples.

The last two bytes are the load address. GRM3 loads at 6000 hex, and GRM4 loads at 8000 hex, which we see there.

 

So what this means, is you have two GRM files, representing the two separate chips (instead of the larger combined file we often see these days). Classic99 won't auto-load that, but in your INI, change the type of the second file back to G, and leave the 8000 load address, and it should work. Likely there are parts of the program missing without that - but it will still show up and launch because the header is in the 6000 GROM.

 

Files set up in the Classic99 INI will recognize and skip that 6 byte header automatically if and only if the first byte is 00 or FF, and the fifth and sixth bytes exactly match the load address in the INI. It doesn't try to parse the data beyond that, relying on what the INI says instead.

 

Well, got it working.  Took both files, removed the 6-byte header, joined the files together and loaded as "funkg.bin" at 6000 and the program seems to work. At least, went through the menus and they all worked.  Before, only 2/3 of the menu worked, so think I may have got it right.

 

Nice thing about this is, you can experiment to your heart's content, you can't break anything.

[Switch1995]

Question about Classic 99 emulation of TurboForth for @Tursi and/or @Willsy.   When I create a 80K BLOCKS file on DSK1, I can go into 1 EDIT and the 1st Block displays fine.  However, every subsequent block edit appears with the character field all in white (pics below).   Any way to get 2 EDIT to display the same as 1 EDIT?  thanks! 

 

Note:  Other than MKBLK, FLUSH, COLD and EDIT, I haven't used any other words of note to display the pics below.

 

 

 

Edited October 7, 2023 by Switch1995

[atrax27407]

To create a series of BLOCKS in TF, type n MKBLK DSKx.filename. "n" is the number of individual blocks in the file. 

 

To access the blocks file (if the name is other than BLOCKS type:

 

S" DSKx.filename" USE 

Edited October 7, 2023 by atrax27407

[Switch1995]

Spoiler

 

That was it!  Thank you, Bob @atrax27407

Edited October 7, 2023 by Switch1995

[+Ksarul]

On 5/12/2023 at 12:13 PM, mizapf said:

If I remember correctly this is one of our Austrian friends, @kl99?

K. Hagenbuchner was really active in the Vienna User's Group BITD, Michael. He also wrote a modified version of the p-System that ran from cartridge space on both the TI and the Geneve, but that software apparently never made it into the wild. I tested it once on my Geneve at the TI Treff in Berlin. It worked great, but I wasn't allowed to copy it. That was the last time I saw anything to do with it, unfortunately.

[+dhe]

On 11/23/2022 at 8:52 AM, retrodroid said:

Woot!  The 64-bit build works!  

@retrodroid  was there any special tricks to getting Classic9 work on wine?

[retrodroid]

On 12/2/2023 at 6:46 PM, dhe said:

@retrodroid  was there any special tricks to getting Classic9 work on wine?

Well to be honest it's been a minute since I set it all up, but going from what I can recall and see in front of me now:

 

If on a Mac you will need the 64-bit build of C99 (classic99_x64.exe), and must also use wine64.

Currently I'm using wine64 stable (wine-8.0.1) installed via brew on my M2 macbook (MacOs 14.1.2) and it's working fine.

 

I believe the wine installer will map a "C:" drive for you (e.g. /Users/xxx/.wine/drive_c/), so once wine64 is installed you can install/copy your classic99_x64.exe somewhere under that directory.  My system also seems to have all .exe file extensions mapped to launch automatically with wine64 so I can just double-click them in Finder, which is how I normally launch my windows apps like classic99_x64.exe and TiCodEd.exe.

 

Operationally, C99 works well, but you cannot use any features that rely on 3rd party windows DLLs, since they won't exist / work on your system. So no custom screen filters, for example.  I've also seen some issues with the screen going to black sometimes if I drag it to another monitor, or resize it by dragging the window border (but not always).  It's safer to use the 2x, 3x etc.  screen size settings from within the C99 menu to adjust the screen size.  A few limitations but it certainly gets the job done.  

[+dhe]

I pulled a mac mini (2011) from a pile and installed High Sierra.

It is still a pleasant drive.

 

Then I installed Wine and the latest version of Classic99 (32-bit) and it ran for me.

[retrodroid]

Ah yes, running an antique system emulated on an obsolete platform - wonderful!  

[Tursi]

7 hours ago, retrodroid said:

Operationally, C99 works well, but you cannot use any features that rely on 3rd party windows DLLs, since they won't exist / work on your system. So no custom screen filters, for example. 

I ship those DLLs... Wine must be able to load DLLs, can't it?