599 replies to this topic

[Willsy]

Awesome job Tursi! This is very handy for me - I'm working on a register editor for the F18A and I plan to use 80 column mode for it. This means I don't have to use MESS, which is good news for me!

THANKS!

[Willsy]

Just tried it. It works just lovely in TurboForth, so I've set my personal system to boot up in 80 column mode (just edit block 1 of the blocks file, insert a line on the top line (CTRL & I) and enter 2 GMODE on the top line)

[Tursi]

Thanks Mark. It was straight forward - there were only three things that were weird - the overwriting of 9918 registers by registers 8-15, the loss of the 4k memory configuration bit, and the fact that two bits in the screen image table pointer register (VDPR2) are hard-coded to 11 - the datasheet didn't explain why this was, anyone know? Is it some masking system?

I would like to make a request to anyone writing code that supports the 9938 and 9958 - when you do your initial register setup, assuming you are going to set a 9918 compatible mode anyway, you can improve compatibility with 9918A and 9918A-derivatives with a really simple change to your process -- set VDP Registers 8-15 BEFORE you set 0-7.

The 9918 masks the register number to 3 bits, so when you do a straight write from 0-15, the values placed in 8-15 overwrite the values in 0-7. But if you do it in the other order (or even 15 counting down to 0), the intended values end up on 0-7 on both chips. As long as you aren't doing anything too fancy with extended memory up front, this solves one of the compatibility issues between the VDPs (as long as you are using 9918 graphic modes!) If TurboForth did that, I would not have had to insert a hack to sometimes ignore registers 8-15

[Tursi]

I finally sat down too, and did a little tips video that I've wanted to do for a long time. If you're curious about some of the extra features, in Classic99, have a look. Hit the YouTube page to see the full description, it includes time marks so you can skip the parts you already know about.



Unfortunately the Windows side text is a bit too small, and the capture wasn't high res enough, but by the time I realized that it was too late to do it again. It should still be possible to follow.

Edited by Tursi, Mon Nov 28, 2011 3:31 AM.

[sometimes99er]

I actually enjoyed this very much (trying to ignore meself being mentioned). Very informative and entertaining (world is falling behind etc.). 37 minutes out the window in no time. Thanks.

[matthew180]

Tursi, on Sun Nov 27, 2011 8:16 PM, said:

and the fact that two bits in the screen image table pointer register (VDPR2) are hard-coded to 11 - the datasheet didn't explain why this was, anyone know? Is it some masking system?

Which two bits?  I don't see a reference to that in the datasheet.  R2 is extended, but nothing I see indicates any hard wired bits.  Can you elaborate?

Tursi, on Sun Nov 27, 2011 8:16 PM, said:

I would like to make a request to anyone writing code that supports the 9938 and 9958 - when you do your initial register setup, assuming you are going to set a 9918 compatible mode anyway, you can improve compatibility with 9918A and 9918A-derivatives with a really simple change to your process -- set VDP Registers 8-15 BEFORE you set 0-7.

I'd like to mention that *not* using the bulk register load feature of the 9938/58 also makes your code more 9918A "compatible", for what it's worth.  Also, the F18A does not suffer from the above masking problem, it will ignore any writes to R8 to R15.

[Willsy]

Great video! I'd kind of forgotten about the clock device. I immediately set about reading it from TF:

FBUF: PC_CLOCK
CREATE BUFFER 80 CHARS ALLOT
S" CLOCK DV0" PC_CLOCK FILE
PC_CLOCK #OPEN DROP
BUFFER PC_CLOCK #GET DROP
BUFFER COUNT CR TYPE CR
PC_CLOCK #CLOSE 

This works, but all three records come across as a single record. Whereas in your BASIC program three record reads were required. I've no idea why....?

It's not really a problem, just curious. Maybe its a feature of BASIC, not the file system.

Mark

[Tursi]

matthew180, on Mon Nov 28, 2011 11:04 AM, said:

Tursi, on Sun Nov 27, 2011 8:16 PM, said:

and the fact that two bits in the screen image table pointer register (VDPR2) are hard-coded to 11 - the datasheet didn't explain why this was, anyone know? Is it some masking system?

Which two bits?  I don't see a reference to that in the datasheet.  R2 is extended, but nothing I see indicates any hard wired bits.  Can you elaborate?

You must be doing something about it - TurboForth sets R2 to >03, which using the normal math would put the SIT at >0C00, instead of >0000 where it really is.

The 9938 Datasheet shows it on page 16, right at the bottom in the Text 2 section under "Pattern name table settings". The text doesn't mention it at all, but the register is documented as:

	MSB   7	6	5	4	3	2	1	0   LSB
R#2	   0   A16  A15  A14  A13  A12   1	1   Pattern name table
												  base address register

Note that bits 1 and 0 are both set to 1. I wouldn't have seen this if TF didn't do it.

Mark, I'll look into your CLOCK observation to see what's up.. glad the video was handy to people!

[Willsy]

Willsy, on Mon Nov 28, 2011 11:09 AM, said:

Maybe its a feature of BASIC, not the file system.

What I mean is, maybe the DSR brings all the records in (up to a record-type maximum length (e.g. 80 or 255 etc) and TI BASIC/XB is actually responsible for delivering separate records (by looking for a comma in the string).

I actually get a single record, like this:

2,11/28/11,20:09:04

[matthew180]

Tursi, on Mon Nov 28, 2011 12:10 PM, said:

You must be doing something about it - TurboForth sets R2 to >03, which using the normal math would put the SIT at >0C00, instead of >0000 where it really is.

The 9938 Datasheet shows it on page 16, right at the bottom in the Text 2 section under "Pattern name table settings". The text doesn't mention it at all, but the register is documented as:

	MSB   7	6	5	4	3	2	1	0   LSB
R#2	   0   A16  A15  A14  A13  A12   1	1   Pattern name table
												  base address register

Note that bits 1 and 0 are both set to 1. I wouldn't have seen this if TF didn't do it.

Ok, I just checked my HDL and those bits are not used, so their value does not matter.  Maybe in the 9938/58 they have to be "11", but the F18A ignores them in Text2.  In text mode (1 and 2), since the tiles per row are no longer a multiple of 2 (40/80 instead of 32), the x and y raster locations can not be used to form the pattern address offset from the name table base.  Normally the name address is formed like this:

ntba & y_pos(1 to 5) & x_pos(1 to 5)

		 0  1  2  3  | 4  5  6  7  8  | 9  10 11 12 13
Address: n4 n5 n6 n7 | y1 y2 y3 y4 y5 | x1 x2 x3 x4 x5

Bits are TI-numbering, so: 0 1 2 3 4 5 6 7 (0 to 255)

ntba = bits 4-7 of R2

y_pos and x_pos are 9-bit counters:

 0   1   2   3   4   5   6   7   8 (0 to 512)
256 128 64  32  16   8   4   2   1

Thus, taking 1-5 from each is the same as dividing by 8, which converts the x,y raster into a 32x24 row and column tile location.  For the text modes you can't do that, thus there is a dedicated "character counter" that is used.  You can see the reference to this counter on page 2-2 of the 9918A datasheet, right in the middle.  My implementation is probably a little different, but achieves the same result.  In text mode 1 it counts from 0 to 959 and is incremented every 6 pixels during the active period.  Using a 12-bit counter to accommodate both 40 and 80 columns, the name address is formed like this:

textpos counter:

 0   1   2   3   4   5   6   7   8   9  10  11 (0 to 4095)
 2K  1K 512 256 128 64  32  16   8   4   2   1

text1:
ntba & textpos(2 to 11)

text2:
ntba(0 to 1) & textpos

		 0  1  2  3  | 4  5  6  7  8  9  10 11 12  13
Address: n4 n5 n6 n7 | t2 t3 t4 t5 t6 t7 t8 t9 t10 t11

		 0  1  | 2  3  4  5  6  7  8  9  10 11 12  13
Address: n4 n5 | t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11

Notice that Text2 ignores the two low bits of the Name Table Base, i.e. from R2.  This is because in Text2 there are between 1920 and 2120 positions (depending on the 24/26.5 rows bit) in the name table, instead of 768 or 960 as in GM1 and Text1.  In GM1 and Text1 you can have the name table in a 1K block, so they use the 4-bits of R2.  In Text2, the name table can be over 2K (in 26.5 row mode), so you start to cut in to the name table base bits from R2.  Since you need 12-bits to count over 2K, you are up to 12-bits for the address, so you lose the bottom two bits of the name table base from R2, i.e. they don't matter.

I don't know why the 9938 would need them set to "11", but the F18A does not care.

Edited by matthew180, Mon Nov 28, 2011 2:45 PM.

[Tursi]

Willsy, on Mon Nov 28, 2011 2:12 PM, said:

What I mean is, maybe the DSR brings all the records in (up to a record-type maximum length (e.g. 80 or 255 etc) and TI BASIC/XB is actually responsible for delivering separate records (by looking for a comma in the string).
I actually get a single record, like this:

2,11/28/11,20:09:04

hah.. that's funny. We were just going over this concept with Walid at the Faire, wondering why the data he was writing with PRINT #1:A,B,C, could not be read with INPUT #1:A,B,C. We eventually decided it was a fact of life, we never even thought of inserting commas, but sure enough... that works.

Walid: are you watching? Put commas between your fields. yes, I just tested it. D'oh.

Anyway, so, yes, what you observe is correct, Mark. I took the clock format from the Corcomp clock manual. MainByte has the manual up here: http://www.mainbyte....tionsmanual.pdf

Classic99 only suports the "CLOCK" DSR, and no register access. It also only supports reading (we don't need an emulator setting the PC clock ).

[retroclouds]

Thanks for doing the classic99 tips video Tursi!

wow, there's so much stuff in classic99 I just didn't know about!

Getting itchy fingers and wanne do some coding on the TI-99/4A again, but unfortunately I'm very restricted as far as TI-time is concerned. Hoping 2012 will be better.

[kl99]

This is some cool video. The manual catches a lot of the stuff as well. I really vote for a live classic99 demo by tursi himself on the Chicago Faire 2012.
Btw: I took the time and read the whole whatsnew.txt file a week ago, and must say: wow! what a progress, now I am able to imagine how much time/work is involved in the emulator that we are able to use thanks to you Tursi.

[kl99]

Is there some place where to share the descriptions for loading v9t9 cartridge roms for usage in Classic 99?
Not talking about the actual roms but entries like this:

[UserCart0]

name="Pole Position"

ROM0=C|6000|2000|MODS\POLEPOSC.BIN

ROM1=X|6000|2000|MODS\POLEPOSD.BIN

I was about to create all those entries for my v9t9 rom collection and wondered if someone did this before?

@Tursi:
How about including all those rom descriptions in the .ini file, and comment them out by default? I know you can't include the actual roms due to legal reasons. However most of the users are having their rom collection named to the above scheme and are using the very same names. That would actually save Users a lot of work.

Is it possible to have a folder structure in the Cartridge\User menu?

[UserCart0]

name="TestFolder\Pole Position"

ROM0=C|6000|2000|MODS\POLEPOSC.BIN

ROM1=X|6000|2000|MODS\POLEPOSD.BIN

My Quicktest with a Folder didn't work.

Can a user add his roms to the Cartridge\Apps or Cartridge\Games Menu?

Thanks Klaus

[RXB]

I have one that is kinda bugged.
[UserCart0]
name="REARXB2012"
message="REA page 0 & RXB page 1"
rom0=G0|6000|A000|MODS\MODULES\REAG.Bin
rom1=G0|6000|6000|MODS\MODULES\REAR.Bin
rom2=G1|6000|A000|MODS\MODULES\RXBG.Bin
rom3=C|6000|2000|MODS\MODULES\RXBC.Bin
rom4=X|6000|2000|MODS\MODULES\RXBD.Bin

The idea is to load RXB 2012 into Page 1 with the XB ROMs and put REA2012 into Page 0.
The reason is from REA2012 it will switch to RXB but not back to RXB 2012 but could not test it correctly in Classic99.
(When you scan empty GROMs in Classic99 it locks up. Understandable as this is not a normal situation.)
I wanted REA2012 to have SuperCart RAM at >6000 and RXB would work fine most of the time from GROM page 1.

[Tursi]

I have one that is kinda bugged.
name="REARXB2012"
message="REA page 0 & RXB page 1"
rom0=G0|6000|A000|MODS\MODULES\REAG.Bin
rom1=G0|6000|6000|MODS\MODULES\REAR.Bin
rom2=G1|6000|A000|MODS\MODULES\RXBG.Bin
rom3=C|6000|2000|MODS\MODULES\RXBC.Bin
rom4=X|6000|2000|MODS\MODULES\RXBD.Bin

The idea is to load RXB 2012 into Page 1 with the XB ROMs and put REA2012 into Page 0.
The reason is from REA2012 it will switch to RXB but not back to RXB 2012 but could not test it correctly in Classic99.
(When you scan empty GROMs in Classic99 it locks up. Understandable as this is not a normal situation.)
I wanted REA2012 to have SuperCart RAM at >6000 and RXB would work fine most of the time from GROM page 1


I am not sure what this one is supposed to be: rom1=G0|6000|6000|MODS\MODULES\REAR.Bin

from the download I got from you, I think this is just a file full of zeros, that some emulators (NOT Classic99) need to serve as a placeholder for RAM? Loading zeros into GROM is the same as loading nothing at all.

Also, that file overwrites rom0, since it loads into the same address on the same GROM base. So you end up with nothing at G0|6000 but zeros.

Try just dropping REAR.BIN. If it really is a "ram" file, you don't need it in Classic99. The rest looks like it should work without that.

This forum's editor is #!$# bugged. If I use quoting on this post, it tells me the quote tags don't match and refuses to post.

[Tursi]

But I can quote in this one just fine. The editor has adopted too many tags, I guess.

kl99, on Thu Dec 1, 2011 5:07 PM, said:

This is some cool video. The manual catches a lot of the stuff as well. I really vote for a live classic99 demo by tursi himself on the Chicago Faire 2012.

Aw, thanks. I've wanted to for a while now, I decided the video was better. As for the manual, I decided what to show by going through the manual, everything I showed is at least mentioned briefly.

Quote

Btw: I took the time and read the whole whatsnew.txt file a week ago, and must say: wow! what a progress, now I am able to imagine how much time/work is involved in the emulator that we are able to use thanks to you Tursi.

Thanks! That goes back to shortly after I ported the emulator to DOS, just before going to Windows. There was probably six months before that, and of course six months or so on the Amiga several years earlier.

Quote

Is there some place where to share the descriptions for loading v9t9 cartridge roms for usage in Classic 99?
Not talking about the actual roms but entries like this:

[UserCart0]

name="Pole Position"

ROM0=C|6000|2000|MODS\POLEPOSC.BIN

ROM1=X|6000|2000|MODS\POLEPOSD.BIN

I'd probably suggest AtariAge, a new thread? hehe. I have an old file I used to include that has all the ROMs I tested back then. While the test notes are probably inaccurate now, the entries should still work. I'll post that in a new thread, people can then be free to update it if they like. Eventually the plan is to move to the MESS RPK format so all this goes away. (Except of course for creating RPKs ). I just don't want to include ZIP libraries. :/

Quote

Is it possible to have a folder structure in the Cartridge\User menu?

That's a neat idea. Today, no. But I'll save it off.

Quote

Can a user add his roms to the Cartridge\Apps or Cartridge\Games Menu?

No to this one, too, these are hard-coded.

[RXB]

So if I drop the REA.Bin how do I get RAM like a SuperCart at >6000 same as EA in page 0, but in the next GROM page 1 I get RXB and the XB ROMS?
(The ROM1 was to make sure it put something I could read at >6000 that corresponed with the RAM/ROM for the REA module like a SuperCart. Had no idea how else to do this.)

Or does Classic99 not work like a HSGPL card so each GROM page has RAM or ROM per GROM pages 0 to 15, it is not like 640K is not available in a PC.

[kl99]

Thanks for sharing the rom ini entries Tursi and RXB.
I will check, if there are roms in my collection not yet in the ini-list asap.

Nice, that you like the folder structure idea for the Cartridge\User Menu.

[RXB]

Hey anyone notice that GROM 0 1 and 2 all have the >1800 to >xFFF used now?

What the heck is there? Those used to be empty now they are not available. I was going to put a menu system in GROM 0 at >1800 now no memory is left?

[OX.]

Hi Tursi,  I'd like to pick your brains on the double loading of roms problem you had - did this cause slowdown on some cart games?  I ask because I'm still getting random slowdown on cart games though Classic99 V3.60 although it does'nt seem as prevailant as in previous versions.  One game in particular seems to suffer more than most - Tunnels of Doom, I suspect this might have something to do with the fact that you also need to set a v9t9 disk image to load the games from.

OX.

[Tursi]

RXB, on Fri Dec 2, 2011 3:53 AM, said:

So if I drop the REA.Bin how do I get RAM like a SuperCart at >6000 same as EA in page 0, but in the next GROM page 1 I get RXB and the XB ROMS?(The ROM1 was to make sure it put something I could read at >6000 that corresponed with the RAM/ROM for the REA module like a SuperCart. Had no idea how else to do this.)

When Classic99 starts, the 9900 has 64K of RAM allocated to it. As you load ROM images, those addresses are marked as ROM. So everywhere that is not ROM and is not devices is RAM. The memory space from >6000->7FFF is RAM unless you load something there, automatically. Classic99 does not require "ram" files and loading them will cause incorrect results.

Quote

Or does Classic99 not work like a HSGPL card so each GROM page has RAM or ROM per GROM pages 0 to 15, it is not like 640K is not available in a PC.

Classic99 does not emulate an HSGPL card or any other GRAM device. So there is no GROM-based paging of CPU memory in there.

[Tursi]

RXB, on Fri Dec 2, 2011 5:27 PM, said:

Hey anyone notice that GROM 0 1 and 2 all have the >1800 to >xFFF used now?
What the heck is there? Those used to be empty now they are not available. I was going to put a menu system in GROM 0 at >1800 now no memory is left?

I'm not certain what you are talking about, but the GROMs used in Classic99 for 0,1,2 are not changed. If you are just examining them from within the emulation, you might just be seeing the emulated ghosting of those addresses. There's nothing there in the standard console GROMs. (There /is/ in the MPD GROMs though).

[Tursi]

OX., on Fri Dec 2, 2011 5:41 PM, said:

Hi Tursi,  I'd like to pick your brains on the double loading of roms problem you had - did this cause slowdown on some cart games?  I ask because I'm still getting random slowdown on cart games though Classic99 V3.60 although it does'nt seem as prevailant as in previous versions.  One game in particular seems to suffer more than most - Tunnels of Doom, I suspect this might have something to do with the fact that you also need to set a v9t9 disk image to load the games from.

No, the issue was unnoticable to most people, just annoying if you had to read the debug log. It was a load-time issue only, when the title page came up it was over.

I have made no adjustments to the timing code in many months, so I would not have expected timing to change at all.

Likewise, needing a disk image attached has no reason to cause a different in performance timing. Even if you read the disk continuously, it's handled by C code and not 9900 code.

[RXB]

Tursi, on Mon Dec 5, 2011 2:58 PM, said:

RXB, on Fri Dec 2, 2011 5:27 PM, said:

Hey anyone notice that GROM 0 1 and 2 all have the >1800 to >xFFF used now?
What the heck is there? Those used to be empty now they are not available. I was going to put a menu system in GROM 0 at >1800 now no memory is left?

I'm not certain what you are talking about, but the GROMs used in Classic99 for 0,1,2 are not changed. If you are just examining them from within the emulation, you might just be seeing the emulated ghosting of those addresses. There's nothing there in the standard console GROMs. (There /is/ in the MPD GROMs though).

Ok thanks, also there does not seem to be any indicator of what AMS bank I am in, I can use RXB to change the banks but it always says >0100 bank, is that GROM or AMS?
I assumed it was AMS but it would most likely be GROM, the AMS would require a full listing of each 4K area of memory and what page was engaged there. Like:
>0000 = >00 default
>1000 = >01 default
>2000 = >45
>3000 = >46
>4000 = >04 default
>5000 = >05 default
>6000 = >06 default
>7000 = >07 default
>8000 = >08 default
>9000 = >09 default
>A000 = >0A default
>B000 = >0B default
>C000 = >0C default
>D000 = >0D default
>E000 = >0E default
>F000 = >0F default

Well you get the idea.