Classic99 Updates

[Tursi]

Ultimately, the DSR code breaks down to a header that lets the TI find the handler for a call, and the code for each type of call. The easiest place to start is with the LOAD PROGRAM opcode, because it's a single call that requires no state tracking. The header only identifies the entry point - for example "DSK1". Everything else comes from the PAB, which is a small structure created in VDP RAM by the program. The most important byte of this is the opcode, since it specifies what is being requested to be done.

 

The actual OPEN/READ/WRITE/CLOSE etc is trickier, because you need to deal with records. There are also a lot of little gotchas to getting it right so it works with all software. Classic99's FIAD code may be helpful for that, I tried to comment anything that was hard won.

 

Then there are some lower level concepts that you need to decide whether you will support. Directory can be accessed two ways on a TI controller - by opening with an empty filename or by reading sectors directly. There's reading and writing sectors (only useful if you're supporting TI compatible disk images), and there are a couple of others like format that I don't support so I don't know.

 

Then on top of all that there's the largely undocumented boot tracking, where some software makes use of side effects from the original disk controller (upon which nearly all updates were based) in order to determine where a program loaded from. Classic99 also supports a few of those, they'll be commented in the disk stuff.

 

But... just getting PROGRAM to work will take you a long way down the road, and it's immediately useful as well. My first pass of Classic99's disk only supported LOAD and nothing else.

[speccery]

Thank you! I think you just saved me weeks worth of work with those comments and guidelines. I'll definitely follow your guidance there and try to get program loading working first. Since I have code to load files from FAT16 formatted partition, I'll start with that. I have my retrochallenge project ongoing too, but this **seems** like not that much work so I'll probably try that too as I want to have disk access too.

 

Responding from my iPhone, lets see if this works...

[Tursi]

New release - very minor updates, but I wanted to get them out there. The main one is addition of fbForth for Lee.

 

The other big one is that scroll lock is no longer related to debug keys - the debug pane being open or not is now the control of that. I'm still getting used to it and so far I don't like it (except for the bug of it not working at all being solved), so there may be tweaks in the future.

 

-TI Artist remapping extended to handle 'TIAM' to '_M' files

-handle truncated sectors when reading FIAD by sector

-fix debug key handling - only active when debug window open. NO MORE SCROLL LOCK.

-tuning of CPU speed

-turn off F18A DPM when reading status register

-more debug on GPU start/stop

-stop GPU when go bit is cleared

-condense palette to F18A palette (now implemented for tiles)

-fix buffer overflow in debug function

-added fbForth 2.09

-alphabetized RXB in the cartridge list

-version 390

 

http://harmlesslion.com/software/classic99

[Asmusr]

Is there a problem with breakpoints in the latest version, they don't seem to work for me at all?

[Tursi]

All debug is tied to the debug window being open... is it?

 

They work for me as long as I remember that... shouldn't be any other condition?

[Asmusr]

The problem seems to be that there are two classic99.exe files in the latest distribution zip file: one in the root folder where breakpoints do work and another in the classic99 folder where breakpoints don't work.

[Tursi]

D'oh! Okay, will fix that

[RXB]

Ran into a snag in Classic99 for SAMS using RXB and the Debugger.

You may know about this or not.

 

From Classic99 using RXB turn on Debugger set to >4000 CPU

Type: CALL AMSINIT ! you see nothing happen?

CALL AMSON

CALL PEEK(16388,X) :: PRINT X

 

For some reason the Debugger window is always empty but according to RXB the values are being loaded or changed?

 

I am working on a new routine in RXB called AMS24K

It swaps the UPPER 24K into two pages of 24K you can switch.

[Tursi]

Sadly paged memory doesn't work well in the debugger, that's definitely on the list. The 32k card and the AMS are currently separate systems though the AMS is almost always present, so I mean to integrate them together.

[RXB]

Sadly paged memory doesn't work well in the debugger, that's definitely on the list. The 32k card and the AMS are currently separate systems though the AMS is almost always present, so I mean to integrate them together.

Thanks that would make my Video Demo no look so silly when i can show how it works using the SAMS and RXB in Classic99

[RXB]

Just update a problem I am having in Classic99:

 

Using RXB type:

CALL AMSINIT ! will default to PASS Mode and load bank numbers for Lower 8K.

CALL AMSMAP ! Switches from default SAMS PASS mode to MAP mode.

CALL AMSON ! Turns on the READ/WRITE Registers of SAMS at >4000 to >5FFF

CALL LOAD(164404,1) ! Loads SAMS bank >01 at >A000 to >AFFF

 

But with the Classic99 Debugger turned on it never changes the SAMS bank shown from 001000 ?

[Asmusr]

Isn't it showing the ROM bank and not the SAMS bank?

[Tursi]

Yes, sorry, the Classic99 debugger doesn't really help with AMS debugging at all.

[RXB]

Yes, sorry, the Classic99 debugger doesn't really help with AMS debugging at all.

Yea it is rather depressing having to confirm everything by using RXB CALL PEEK and CALL LOAD.

[Tursi]

Minor update:

 

-Patch for XB256 'DELAY' call

-Fix for disk CLOSE causing type mismatch

-Fix for VDP memory overrun in disk systems (for data that ended exactly at >4000)

-Make inverted carts respond to '9' instead of '3' for extension ('3' still supported)

-Make VDP screen redraw when breakpointed

 

Classic99 391 - http://harmlesslion.com/software/classic99

[RXB]

Ok I am going out of my mind with Classic99!

I can not write to GRAM in the latest version!

It always crashes and no matter in Windows 10 what I do several things are wrong:

1. I can not run any other app in Windows 10 while running Classic99 as it stops the second I change any app, Classic99 just STOPS!

2. No matter what I do Folders lock in Classic99 so I can no longer write to them. Fix permissions like 40 times a day!

3. GRAM write always crashes using GPL@LOADER! I am DEAD IN WATER with Classic99!

 

WTF is going on ?

Edited November 9, 2016 by RXB

[+Schmitzi]

Maybe just one of the million Win10-problems ?

Is Classic99 supported on Win10, or is this an early test ?

[Asmusr]

I have been running Classic99 in Windows 10 for the last year without problems, but I never write to GRAM. There is an option called "Pause when window inactive" that might have something to do with Classic99 stopping.

[Tursi]

That Pause would be my first guess too... check that under Options, Rich.

 

I haven't touched the GRAM stuff in a long time, but I'll take a look. I can't imagine there's anything in there that works differently under Windows 10, it's all internal code.

 

As for permissions I don't know what to tell you. A running Classic99 /never/ writes to the disk unless you the user explicitly save something.

 

I do support Windows 10 but I don't run it myself anymore.

[Tursi]

(The GPL@LOADER crash is very possible, since I did make changes to the disk system in this release. I will check that too.)

[RXB]

(The GPL@LOADER crash is very possible, since I did make changes to the disk system in this release. I will check that too.)

100% confirmed going back to a Classic99 version I had on DVD from 2011 works GREAT with no GRAM crash.

 

Whatever you did really messed up Disk and GRAM.

[Tursi]

Rub it in, Rich.

 

Not having much to load, I went back to the code you provided in this message: http://atariage.com/forums/topic/165901-classic99-updates/?p=2336378

 

Which was your GPLHOW2 XB2GPL demo. That loads and runs fine in Classic99 391. Can you maybe post the object code that is crashing GPL@LOADER now so I can see why?

[RXB]

Ok,from current Classic99 set up RXB 2015E and load GPL@LOADER to load this Object Code and I also include the Source.

 

Sorry not trying to embarrass you, just exited that after a week of messing up my permissions figured out it was not my computer files but Classic99

 

RXB 2016 GRAM 6.zip

[Tursi]

I can find no reason to support that your permissions issue is Classic99, I don't write to the disk except when you save a file. I haven't changed anything that would impact that -- you have full source for the emulator. If you can find /anything/ in there that touches file permissions I'll fix it.

 

I can't even suggest what it might be, I've not heard of that issue... but I think a Google search would be in order there.

 

Okay... so from TI Editor/Assembler GPL@LOADER loads ORXB6 without any issue. If I select RXB2015E from the menu, then start with menu, the select Editor Assembler (deliberately going the long way to give the bug the most chances to reveal), then run GPL@LOADER, then load ORXB6, it also works. I also tried directly to REA from the main menu.

 

I tried both with the TI controller hack enabled and disabled, no change. The loaded RXB seems to run fine.

 

Now, one thing I /did/ note, if I /only/ enable GRAM on >C000, then at the very end of the load GPL@LOADER reports "NO GRAM", as if it tried to spill over into >E000. Is /that/ the issue you are seeing? (I wouldn't describe that as a crash, despite the noise it makes ). If I enable both >C000 and >E000 it loads successfully.

 

For that case, the last record is loading (according to the screen) at >DFEA, so if the last record loads more than 21 bytes, it would indeed spill over. I can't explain why the disk changes would affect that - are you sure that's the only difference?

[+arcadeshopper]

If you accidently open two classic99s you might run into a file locking issue.. on any ver of windows..

 

Greg