Classic99 Updates

[+OLD CS1]

So anyone know who called the cops ?

 

So we can put a hit on 'em?

 

[sometimes99er]

So anyone know who called the cops ?

Let's for one minute assume I did it. Does it make any difference ? As you said, move on.

 

[marc.hull]

So anyone know who called the cops ?

Let's for one minute assume I did it. Does it make any difference ? As you said, move on.

 

 

Well it was a rhetorical question Karsten but....... I'd like to see if anyone owns up to it. I suspect it was one of the participants of the "unbelievably atrocious exchange of verbiage 2011." Perhaps a late comer who took a snide shot and then called mommy when his feelings got a bit mashed. Guess it really doesn't matter and we will never know since big brother erased the events from history and I doubt that whomever did do it will say so.

 

Some of you guys are really neat and I enjoyed chatting and playing with you. Some unbelievable talent here and I'm a better man to have known you.

 

Lately it's been getting a bit cliquish here for my tastes and the narcissism meter for some seems constantly pegged. This last event with the moderator......? Really ???? Call the moderator ?

 

 

I hope this forum gets back to what it was intended to be (which was a TI game programming group.) Hopefully it will.

[Tempest]

I think you guys are really getting too hung up on this. But for the record, it wasn't just one person who reported the posts. I looked at the reported posts and decided to remove them. I did restore some of the deleted posts after re-reading them, but the rest of the posts will stay deleted.

 

That being said, I really hope everyone will step back and take deep breath. Life is too short to get worked up over things this trivial.

 

Tempest

[sometimes99er]

Well it was a rhetorical question Karsten but....... I'd like to see if anyone owns up to it. I suspect it was one of the participants of the "unbelievably atrocious exchange of verbiage 2011." Perhaps a late comer who took a snide shot and then called mommy when his feelings got a bit mashed. Guess it really doesn't matter and we will never know since big brother erased the events from history and I doubt that whomever did do it will say so.

 

Some of you guys are really neat and I enjoyed chatting and playing with you. Some unbelievable talent here and I'm a better man to have known you.

 

Lately it's been getting a bit cliquish here for my tastes and the narcissism meter for some seems constantly pegged. This last event with the moderator......? Really ???? Call the moderator ?

 

I hope this forum gets back to what it was intended to be (which was a TI game programming group.) Hopefully it will.

Rhetorical or not, I still hear you wanting to know - who called the cops.

 

This is a hobby. It's supposed to be fun. If something irritates me I have to consider to ignore and move on fast. Seeking what for me is positive.

 

The group has evolved. It's become almost anything TI-99/4A related. Fine with me. I'm an emulator guy only, mostly interested in the game aspects. I'm more or less staying clear of many hardware projects. They're nice etc., but my interest is elsewhere. With the present activity level (number of posts), I think one forum is fine.

 

Thanks to the moderators for trying to moderate. It's not an easy job.

 

Edited August 24, 2011 by sometimes99er

[+retroclouds]

ok, here's a question related to the further enhancement of classic99

 

How mouch effort would it be to update memory (VRAM, RAM & GRAM) from inside the debugger ?

I'm thinking about halting the CPU, going to the memory window in the debugger, say VRAM address >0020 and overwrite it with the byte value >CC.

Afterwards I press F1 to let the program continue. Would be cool if the memory window could be turned into a memory editor

 

What would the pitfalls be? I mean sure, updating certain memory locations could make your TI-99/4A crash.

But what about the emulator itself, would a lot of extra measures be required to implement a memory editor?

[sometimes99er]

How mouch effort would it be to update memory (VRAM, RAM & GRAM) from inside the debugger ?

That would be very nice and useful for different experiments, debugging etc.

 

Full window editing would be pure luxury. I could settle for single byte manipulation.

 

I then did something stupid (entering 8300=33) and was surprised to see this ...

 

 

[Tursi]

How mouch effort would it be to update memory (VRAM, RAM & GRAM) from inside the debugger ?

I'm thinking about halting the CPU, going to the memory window in the debugger, say VRAM address >0020 and overwrite it with the byte value >CC.

Afterwards I press F1 to let the program continue. Would be cool if the memory window could be turned into a memory editor

 

What would the pitfalls be? I mean sure, updating certain memory locations could make your TI-99/4A crash.

But what about the emulator itself, would a lot of extra measures be required to implement a memory editor?

 

As Sometimes99er discovered, that's been in there for a long time (except for the nice full-screen editor, which I'd like too, someday).

 

It used to be that you just entered <address>=<val>, and depending on whether you were viewing CPU, VDP or GROM memory, that was what was updated. But I keep hitting cases where I wanted to watch one thing and change another, and manipulate registers/etc without changing tabs. So I changed to a prefix-based system and added that pop-up window to let old-timers know that it changed.

 

These are the things you can type in that little entry box at the bottom of the debugger window and hit apply. Section 7.7 of the manual (Changing Memory) goes into a little more detail. All numbers (xx or xxxx) must be in hex - length matters in some cases. Two characters mean a byte and four mean a word. (For CPU memory only, all else is 8-bit).

 

PC=xxxx = change the program counter to xxxx.

WP=xxxx = change the workspace pointer to xxxx.

Cxxxx=yy = change a byte at CPU address xxxx to yy. If ROM is accessed, the emulator will ask whether you mean to simulate a write to the ROM (ie: bank switching) or change the ROM (temporarily).

Cxxxx=yyyy = change a word at CPU address xxxx to yyyy. Same deal with ROM.

Vxxxx=yy = change a byte of VDP RAM at xxxx to yy.

Gxxxx=yy = change a byte of GROM at xxxx to yy. The emulator will confirm the change, there's no write simulation.

Rx=yy = change the high byte of CPU register x to yy. (Note this ends up being a CPU memory write, but you don't need to add the WP yourself).

Rx=yyyy = change the full word of CPU register x to yyyy.

VRx=yy = change the VDP Register x to yy

 

These are all active whether the emulator is breakpointed or running, but I recommend breakpointing first to avoid unexpected behaviour if it happens to race with the program's execution. It's there, and it works. It's a bit of a pain to change multiple bytes, but that too can be done.

 

The main things that you can't do in here easily are setting the VDP or GROM addresses, the sound chip registers, or modifying non-active bank-switched pages. But because you can hit the bank-switch addresses with the C command, with a little manual effort (and some care!), you can manually bitbang all these things from this interface.

Edited August 25, 2011 by Tursi

[sometimes99er]

Cxxxx=yy = change a byte at CPU address xxxx to yy. If ROM is accessed, the emulator will ask whether you mean to simulate a write to the ROM (ie: bank switching) or change the ROM (temporarily).

 

... you can manually bitbang all these things from this interface.

Hehehe, I love it. Maybe now I should print the f*ckin' manual, take it to the terrace and watch that shadow catch up with me.

 

Edited August 25, 2011 by sometimes99er

[Willsy]

ok, here's a question related to the further enhancement of classic99

 

How mouch effort would it be to update memory (VRAM, RAM & GRAM) from inside the debugger ?

I'm thinking about halting the CPU, going to the memory window in the debugger, say VRAM address >0020 and overwrite it with the byte value >CC.

Afterwards I press F1 to let the program continue. Would be cool if the memory window could be turned into a memory editor

 

What would the pitfalls be? I mean sure, updating certain memory locations could make your TI-99/4A crash.

But what about the emulator itself, would a lot of extra measures be required to implement a memory editor?

 

That feature has been in the debugger for a very long time! Press the ? button in the debugger! Lot's of nice features explained in there!

[+retroclouds]

Excellent! I didn't know it was in there already!

 

Yes, memory editor would be nice but I'm more than happy with the feature that's in there now

 

I should really read the manual

[Tursi]

The manual was written to be read, but since I am told that I failed at that, it's probably still best as a reference. Load it up, skim the table of contents for what you want, and jump to it (or just keyboard search). At least all the instructions are in one document now.

[+OLD CS1]

The manual was written to be read, but since I am told that I failed at that, it's probably still best as a reference. Load it up, skim the table of contents for what you want, and jump to it (or just keyboard search). At least all the instructions are in one document now.

 

What? Who skips the docs??

[TEXAS_JOE]

The manual was written to be read, but since I am told that I failed at that, it's probably still best as a reference. Load it up, skim the table of contents for what you want, and jump to it (or just keyboard search). At least all the instructions are in one document now.

 

What? Who skips the docs??

mmmm .... I think Tursi meant, Get to the part that is relevant to you. Unless of course you enjoy sitting and reading the entire document when all you need is a disk I/O reference.

[+OLD CS1]

What? Who skips the docs??

mmmm .... I think Tursi meant, Get to the part that is relevant to you. Unless of course you enjoy sitting and reading the entire document when all you need is a disk I/O reference.

 

Oh, I get his point, but I meant that I have been one of the offenders of not reading the well-written documentation.

[TEXAS_JOE]

What? Who skips the docs??

mmmm .... I think Tursi meant, Get to the part that is relevant to you. Unless of course you enjoy sitting and reading the entire document when all you need is a disk I/O reference.

 

Oh, I get his point, but I meant that I have been one of the offenders of not reading the well-written documentation.

hehehe

[Tursi]

Oh, I get his point, but I meant that I have been one of the offenders of not reading the well-written documentation.

 

hehe... nobody blames you! Rich's daughter gave a professional review of my documentation, and it was not flattering.

 

But that's the best you're gonna get out of me.

[+OLD CS1]

hehe... nobody blames you! Rich's daughter gave a professional review of my documentation, and it was not flattering.

 

But that's the best you're gonna get out of me.

 

I find that those who write software do a great job at the software, but not such a hot job at the documentation. IMNSHO, this is why a lot of F/OSS fails, because you have a group of great software people working the project. Engineers often see things from a particular perspective which is not always user-friendly.

 

Pretty much the same as web developers and server admins. You are generally one or the other, but hardly ever both. I am an admin, and a damn good one if I say so myself, but I do not do anything in PHP or *SQL that I would dare pass of as professional quality deserving of the title "web design."

 

TL;DR. On the scale of programmer versus writer, I say your scale tips VERY much toward one side versus the other.

 

(But, by all means, PLEASE continue to document!)

[RXB]

The real problem with manuals is that they take a equal amount of time to write as the software did. It is a real pain to work on software for 6 months then spend the next 6 months making the documents.

 

I should explain that the reason for the time is dreaming up examples and showing how they work, then the next step is to make demo programs the user can look at and use.

 

Usually in a software company you have people that do one job or the other. Doing this alone is very hard on the programmer as now he has become a teacher and instructor.

 

If all these jobs are done equally the product is always a hit.

Edited August 27, 2011 by RXB

[sometimes99er]

I just want to say, that I think Tursi's made a fine manual. Thank you.

 

[RXB]

I just want to say, that I think Tursi's made a fine manual. Thank you.

 

 

Examples like Cartridges would be immensely helpful as I never used V9T9 ever, so I used PC99 just like 90% of the people I know. Just a fact.

 

Talking to former TI people that was the last thing they used was PC99. I only know one guy that used V9T9, but he moved out of state.

 

It is cool that you like the docs the way they are, but imagine the pain I have trying to make updated Cartridges work with no example and fresh to Classic99.

 

A example is the Hex Editors (using Neo), never touched or used one till Classic99. Please show a little sympathy.

[RXB]

Ok again I am at a loss as to why I can not get Cartridges to load into Classic99.

 

First what I want to do is load REA at GROM Page 9 and RXB at GROM page 0. There are 16 pages of GROM so I should be able to do this from Classic99.ini file.

 

But so far I can only get RXB or REA to load and never both. Now neither loads and I did not change the REA one at all? (Also no errors are indicated from the Classic99 debugger?

 

 

Included zip so please help.

RXBREA.zip

Edited September 5, 2011 by RXB

[sometimes99er]

I just want to say, that I think Tursi's made a fine manual. Thank you.

 

Please show a little sympathy.

This is not meant to be an attack on you. The manual can be judged relative to different standards and/or needs. Whatever, I just wanted to let Tursi know, that I think he did a good job. The alternative could be no manual at all. I'd rather see the software develop than some heaven sent manual (expect it to be 2,000+ pages). He can't possibly please everyone, their style, language and other needs.

 

[RXB]

I just want to say, that I think Tursi's made a fine manual. Thank you.

 

Please show a little sympathy.

This is not meant to be an attack on you. The manual can be judged relative to different standards and/or needs. Whatever, I just wanted to let Tursi know, that I think he did a good job. The alternative could be no manual at all. I'd rather see the software develop than some heaven sent manual (expect it to be 2,000+ pages). He can't possibly please everyone, their style, language and other needs.

 

 

Tursi did the best he could with the time alloted I suspect.

 

Just saying when I have an example I can figure out more then the manual can explain sometimes. Looking at how it is done vs just being told T|AAAA|LLLL|filename means how do you figure out what is wrong?

 

I get a error, but have no reference to look at as to what is correct vs what is incorrect, I am stuck with a incorrect and nothing else. Maybe you could help me.

[Tursi]

Examples like Cartridges would be immensely helpful as I never used V9T9 ever, so I used PC99 just like 90% of the people I know. Just a fact.

 

Rich. There is an example for cartridges in the manual. The specific example is how to load AtariSoft's Pole Position. In addition, I have personally written you at least a half-dozen personal examples. Are you taking anything away from the examples or just taking them as ready-to-go?

 

V9T9, I understand I think why you mention it, but it is not relevant here. V9T9 has a completely different method for loading cartridges into the emulator. Classic99 just uses the V9T9 ROM naming scheme for automatic ROM loading only (ie: without touching the INI), because before the RPK format was released, 95% of the ROM images out there were in this format. Classic99 today does not have any support for creating new cartridges, and that's why you have to do it by hand with a cryptic coded INI string. The filename has no relevance to the INI file, but people tend to use the old convention to make it clear what file is what.

 

Classic99 is distributed as a BETA state product. You are warned before you download it. All I ask is that you take your time and read everything you have been given. If you don't understand, please ask targetted questions about the documentation that confuses you, instead of "please solve this for me, the documentation is terrible". That serves a dual purpose - first, it helps you understand better than a raw solution, and second it provides targetted areas for improving the documentation.

 

It is cool that you like the docs the way they are, but imagine the pain I have trying to make updated Cartridges work with no example and fresh to Classic99.

 

You have shared your pain quite well, Rich. You have even gone so far as to cast insults about it. Yet I, and others (which I appreciate), have tried to help you. I have probably spent more hours sorting out your problems than it would have taken to write a cartridge creator tool. These replies are not off the cuff. I test and verify everything I write. This one has taken me two and a half hours. How long did you spend collecting information for me to work from?

 

Please show a little sympathy.

 

I would ask the same of you. I'm personally not interested in providing a manual that John Q. Public can pick up, and use to create ROM images with. Even if someone else wrote it! (Because I would have to spend a fair bit of time verifying all the information in such a thing.) Classic99 covers the casual user with it's generic ROM loader, which works well enough often enough for that to be enough. For everyone else, I ask a little more than the average emulator since I am more interested in internals than user interface. Maybe someday, in the distant future when the important stuff is done.

 

The future plan for cartridges will be the MESS RPK format, so you are going to have to learn another format that is, IMO, even more cryptic, unless you love XML already. Eventually the emulator will let you create them directly, but that's further out because the GUI for such a thing is difficult to do well. RPK is a good choice because it is well supported, and is extensible to any format needed while containing all needed information in just one file.

 

I'm honestly rather happy with the manual, whatever your daughter may say, and since no improved example was forthcoming, I take those comments as back-handed rather than constructive criticism. It covers all the areas of the emulator, it /does/ provide examples, screenshots, and detailed explanations, and contains back story and history. It even contains a little hidden intrigue, since that was requested. The areas that you are having problems with are less a documentation issue, IMO, and more a case of incomplete functionality.

 

First what I want to do is load REA at GROM Page 9 and RXB at GROM page 0. There are 16 pages of GROM so I should be able to do this from Classic99.ini file.

 

But so far I can only get RXB or REA to load and never both. Now neither loads and I did not change the REA one at all? (Also no errors are indicated from the Classic99 debugger?

 

When you have a problem like this, please explain the evidence you are using for your conclusion! Why do you say they are not loading? How are you checking? There's nothing to troubleshoot for you otherwise! As the person demanding better documentation, in return I will demand better problem descriptions.

 

This is what you provided in your Classic99.ini:

 

[userCart0]

name="RXB/REA"

message="RXB page 0 & REA page 9 GROM"

rom0=G0|6000|2000|MODS\RXB2001C.bin

rom1=G0|6000|2000|MODS\RXB2001D.bin

rom2=G0|6000|A000|MODS\RXB2001G.bin

rom9=G9|6000|A000|MODS\MODULES\REAG.Bin

 

AGAIN, I will break down the meaning of each part of the line, using this one as the example: rom0=G0|6000|2000|MODS\RXB2001C.bin

 

The line is a pipe-delimited record with four fields, starting after the equals sign. They are Type, Load Address, Size, Filename.

 

rom??= -- these are the indicators for ROMs to load, and specify the record will follow. They start at 0 and count up. In this list, rom0 is the first line loaded, and rom9 is the last rom loaded in this example. The number used here is just for the order, it has nothing to do with where the data goes or what type of data it is. Therefore, you could equally have used rom0,rom1,rom2,rom3, or rom10,rom15,rom20,rom30, and the effect would be the same. I recommend lines start at 0 and continue sequentially without gaps. Please ask if you do not understand this fully, this is an area that you repeatedly confuse.

 

G0 = this is the type column. 'G' means GROM, and a number means a specific GROM page, instead of 0. G0 would specify page 0 (so the 0 is optional). There is a complete list of type codes in the manual, and only GROMs have a page index. You must tell the emulator what type of memory you are loading here, GROM (G) or CPU ROM © (for most cartridges - there are other types including bank switching pages for Extended BASIC (X), new formats like 379 bank-switching (3), and more exotic types most cartridges will not use.)

 

6000 = this is the load address in the TI memory map. In this case, it means to load at GROM address >6000. The load address for TI GROM and CPU memory ranges from >0000->FFFF, but the emulator will not allow you to overrun known ranges. (For instance, a CPU cartridge at >6000 can not load more than 8k, and GROM at >6000 can not load more than 40k).

 

2000 = this is the size of the ROM data. In this case, it means the data is >2000 bytes long. If this size does not match the size of the actual file loaded, a warning is displayed in the debug log, and this value is used instead of the length of the file.

 

MODS\RBX2001C.BIN = this is the filename of the ROM. It's a standard DOS/Windows filename, so without a drive specifier it's relative to the application folder. If this file can not be found or opened, the error is logged only in the debug log (this is something that will be improved in the future).

 

So here is what your instructions do:

 

a) Loads MODS\RXB2001C.BIN as 8k of GROM to page 0 at >6000

b) Loads MODS\RXB2001D.BIN as 8k of GROM to page 0 at >6000

c) Loads MODS\RXB2001G.BIN as 40k of GROM to page 0 at >6000

d) Loads MODS\MODULES\REAG.Bin as 40k of GROM to page 9 at >6000

 

Here is what the Classic99 debug log reports when you load this cartridge (with the files in the correct folders):

 

Loading file (MODS\RXB2001C.bin) from disk: Type G, Bank 0, Address 0x6000, Length 0x2000

Loading file (MODS\RXB2001D.bin) from disk: Type G, Bank 0, Address 0x6000, Length 0x2000

Loading file (MODS\RXB2001G.bin) from disk: Type G, Bank 0, Address 0x6000, Length 0xA000

Loading file (MODS\MODULES\REAG.Bin) from disk: Type G, Bank 9, Address 0x6000, Length 0xA000

Setting top of VRAM to >37D7 (3 files)

 

The debug log tells you /exactly/ what the emulator is doing with the load. You have access to this with a single menu click. You can see it tells you the type, the bank, the address and the size. If the size is defined wrong, it will warn you about that. And if you look carefully, you'll see that you loaded all three RXB2001 files on top of each other in GROM space. From the filenames, I would assume that the C and D files are ROM data with an Extended BASIC banking scheme. (Normally, 'C.BIN' would be a 'C' type instead of 'G0', while 'D.BIN' would be an 'X' type instead of 'G0'.) You can see that REAG.BIN loaded exactly where you expected it to - GROM bank 9 at >6000.

 

I actually get the full menu after this, but of course RXB will crash with the ROM files in the wrong place.

 

Think of it as building a physical cartridge by hand. You have to wire up the 'chips', being the individual files, to the right addresses. Also remember you are NOT using a GRAM Kracker. There may be things that it does that I am not aware of.