in praise of the F18a

[+hloberg]

Had to say this; just installed the F18a and WOW. it was so easy to install and the picture is great!

The only hard part is cutting the hole for the plug.

The only program I, so far, have problems with is 'The missing link'. keep getting, 'out of memory' and Stack memory goes to 0. Since I don't use it much, don't care.

on the other hand It might be my imagination but the graphics seem faster.

can't wait to delve into some of the extended features.

Edited April 2, 2014 by hloberg

[matthew180]

hloberg, I'm glad you like your F18A. Is "The Missing Link" a program that works with the original 9918A? There is a thread here in the forum that lists programs that require a 9938, yet work with the F18A. Keep in mind that the F18A is a 9918A replacement and does does not have the extended memory of the later VDPs (9938/58). The F18A does implement the 80-column mode of the 9938, so some programs will work (see the thread I mentioned) as long as they don't use or assume there is VDP memory over 16K.

[TheMole]

If I understood it correctly, TML is set of subprograms that allow you to use bitmap mode from XB. I think senior_falcon wrote it back in the day. It is targeted at the 9918a though, so it'd be interesting to know what the problem is...

[matthew180]

You probably need the 32K RAM expansion (a PEB) or the CF7+/NanoPeb then. I have never messed with TML so I don't know the details, however if something works on the 9918A, then it should also work on the F18A. Were you able to run TML prior to installing your F18A?

[+hloberg]

able to run it on the emulator fine. Senior Falcon re-released it a little while back and it's in the development resources.

I remember testing TML with the CF7+ before I got the F18a and it worked fine. But I can't remember if I tested running a program, that's where it runs out of memory. The program runs in Ex BASIC.

The program uses up most of the VDP memory as it starts up in the bit-map mode and stays in the bit map mode while you are in the editor. Even running normal it only has about 7k of stack space max.

I'm sure it does a lot of weird alchemy in the VDP so I'm not surprised it has issue.

It's not a big deal but I thought I might mention it, just so you would know. Might want to talk to Senior Falcon. He might released a new version that does work I haven't tried.

[senior_falcon]

I'd need more information to know what's going on. Was this program written for The Missing LInk? Does it run on a TI without the F18A? Remember that there is a very limited amount of stack available, especially when running in the full color mode. You have almost 13K of the VDP used up for the pattern, color and screen tables, plus memory needed for disk buffers and sprites. which doesn't leave a lot of room for strings. Try a simple program like:

10 FOR I=10 TO 100 STEP 10::CALL LINK("CIRCLE",96,120,I)::NEXT I and see if that runs. (No manual in front of me so I'm not sure that program is right. If not you should be able to fix it). I'm not sure TML is compatible any more with a myarc controller which maps out the VDP differently.

[matthew180]

@hloberg, can you give me some step-by-step instructions to reproduce the error you are having? I would like to confirm if this problem is F18A specific, and if so I will do everything I can to fix it.

[+hloberg]

I'm going to reload the TML with the latest tonight, to be sure. then re-test. I'll let you know.

[+arcadeshopper]

I've had some issues with the NanoPEB with the f18a.. turns out the sidecar looks for vdp a few milliseconds before the f18a is ready.. Jamie is working on a new model to fix this that delays the nano a few more to time it right.. Might be the issue if you have weird assembly issues.

 

Greg

[senior_falcon]

I was wondering how you got a stack space of around 7K and did some tests to refresh my memory. Right after you load and run TML you will get a Texas shaped cursor and a green screen. If you then type size you see: 7895 BYTES OF STACK FREE and 15280 BYTES OF PROGRAM SPACE FREE. The program has erased itself after running, but the pointers are not updated. If you enter NEW or add any line then they get updated. After NEW, then SIZE you get the true numbers: 1460 bytes of stack and 24488 bytes of program space free. These are the default values for 1 disk file available and 16 colors. Hold any key down when loading to get a menu that lets you choose values other than these. BTW, I tested the one liner above and it works as expected.

[+hloberg]

I'd need more information to know what's going on. Was this program written for The Missing LInk? Does it run on a TI without the F18A? Remember that there is a very limited amount of stack available, especially when running in the full color mode. You have almost 13K of the VDP used up for the pattern, color and screen tables, plus memory needed for disk buffers and sprites. which doesn't leave a lot of room for strings. Try a simple program like:

10 FOR I=10 TO 100 STEP 10::CALL LINK("CIRCLE",96,120,I)::NEXT I and see if that runs. (No manual in front of me so I'm not sure that program is right. If not you should be able to fix it). I'm not sure TML is compatible any more with a myarc controller which maps out the VDP differently.

ran test program. got 'out of memory' in 10. showed 0 bits stack free.

Your right, forgot to mention after type NEW get 1460 bytes.

I will try running holding down the key to try other versions and let you know.

[senior_falcon]

Post the program here or PM it to me and I'll take a look. Between Matthew and I we should be able to resolve this.

[+hloberg]

OK. ran the test program, and after a few reboots, it ran OK in both the 16 and 2 color modes. but, can not save or load while in TML, always locks up the computer. outside TML, SAVE and LOAD fine. tried to load TMLDEMO, lock up. Tried both 2 color and 16 color modes, same thing.

as arcadeshopper said it's probably something to do with using the f18a with the cf7+.

Funnelweb had to be modified to work with the cf7+.

I'm going to test the CF7+ without the voice syn. next. I have had issues ever since I attached it.

same even without speech

Edited April 3, 2014 by hloberg

[senior_falcon]

Can you (or someone else) try running TML and then the TMLDEMO without the cf7+ . i.e. with the F18A and a standard TI PEB. I seem to remember that the cf7 uses a couple extra bytes of VDP ram. Actually, you should be able to check this by typing NEW when in XB. Without the cf7 I get 11840 and 24488 bytes. If it is different using the cf7 then the missing link might need a minor adjustment.

[+hloberg]

with cf7+ ext 24488 stack 11832.

I don't have a machine with a real PEB currently.

Edited April 3, 2014 by hloberg

[senior_falcon]

Here's something you can try:

OLD DSK1.TML

RUN

NEW

SIZE

and you should get 1460 and 24488

then:

CALL PEEK(-31888,A,B)

PRINT A;B

they should be 29 and 243

CALL LOAD(-31888,29,235) (or 8 less than the value returned in B)

NEW

SIZE

and you should get 1452 and 24488

OLD DSK1.TMLDEMO

RUN

and hopefully it will run OK. Let me know.

[+hloberg]

Here's something you can try:

OLD DSK1.TML

RUN

NEW

SIZE

and you should get 1460 and 24488 >>>I get 1452 and 24488

then:

CALL PEEK(-31888,A,B)

PRINT A;B

they should be 29 and 243 >>> I get 29,235

CALL LOAD(-31888,29,235) (or 8 less than the value returned in B) >>> I input 29,227

NEW

SIZE

and you should get 1452 and 24488 >>> i get 1444 and 24488

OLD DSK1.TMLDEMO >>> still locks up

RUN

and hopefully it will run OK. Let me know.

[senior_falcon]

That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB:

CALL INIT

OLD DSKn.TML

CALL PEEK(-7283,X)::PRINT X

that should be a 5 - if so then:

CALL LOAD(-7283,13)

RUN

and then try loading and running TMLDEMO

Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access.

[matthew180]

I have a CF7+ and have not had any problems myself, then again my use these days is generally limited to running F18A test programs from the E/A cart. However, it looks like this is panning out to be a slight PEB vs. CF7+/Nanapeb difference.

[+Lee Stewart]

That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB:

CALL INIT

OLD DSKn.TML

CALL PEEK(-7283,X)::PRINT X

that should be a 5 - if so then:

CALL LOAD(-7283,13)

RUN

and then try loading and running TMLDEMO

Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access.

 

Unless I'm missing something, >8370 should not be changed by a program. It should always point to the highest available byte of VRAM, i.e., the first free byte below the disk sector buffering area in VRAM. It is changed by DSRs when they reserve buffer space at the top of VRAM. Indeed, the CF7/nanoPEB DSR reserves 8 extra bytes at the very top of VRAM before the "disk" sector buffers and filename area are reserved by the likes of CALL FILES(n). I don't know anything about TML, but if the user can do a CALL FILES(n) any other way than through TML, >8370 will be changed, thus destroying your pointer. Also, moving any part of the VRAM disk buffering area somewhere else I should think would destroy the integrity of the DSR's buffer space.

 

...lee

[+hloberg]

That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB:

CALL INIT

OLD DSKn.TML

CALL PEEK(-7283,X)::PRINT X

that should be a 5 - if so then:

CALL LOAD(-7283,13)

RUN

and then try loading and running TMLDEMO

Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access.

value of X was 5 but no change. still will not save or load.

after work will try more test.

[senior_falcon]

 

Unless I'm missing something, >8370 should not be changed by a program. It should always point to the highest available byte of VRAM, i.e., the first free byte below the disk sector buffering area in VRAM. It is changed by DSRs when they reserve buffer space at the top of VRAM. Indeed, the CF7/nanoPEB DSR reserves 8 extra bytes at the very top of VRAM before the "disk" sector buffers and filename area are reserved by the likes of CALL FILES(n). I don't know anything about TML, but if the user can do a CALL FILES(n) any other way than through TML, >8370 will be changed, thus destroying your pointer. Also, moving any part of the VRAM disk buffering area somewhere else I should think would destroy the integrity of the DSR's buffer space.

 

...lee

This is a creative and undocumented use of the disk buffer space. When you do a CALL FILES(n) the TI allocates disk space working down from V3FFF and sets >8370 to point to the first available memory space below the 5 byte header. That pointer lets XB know where the stack should start and probably is what tells the disk system where the buffers can be found. I discovered that by moving that 5 byte buffer I could put it where I wanted instead of where TI thought it should be. The disk buffers are indexed to the pointer so they just go along for the ride. This way TML can reserve space for disk buffers AND buffers for all the bit mapped stuff. What happens when TML starts up is that it copies the TML routines from high memory to low memory, starts up an interrupt routine, does the call files, moves the aforementioned header, changes the pointer at >8370, erases the loader program and returns to XB. The TI then goes about business as usual with no clue that the pointers are "wrong". It can load and save programs and doesn't seem to care about the changes. Note that this applies to the TI and Corcomp disk controller. The Myarc controller is a different animal - it is not indexed to the header. It is indexed to >3FFF so the buffers don't move with the header. So TML has to be mapped diffferently for the Myarc controller. It may be that CF7 works like the Myarc controller or maybe completely differently from either one.

[+Lee Stewart]

This is a creative and undocumented use of the disk buffer space. ...

 

Nice!

 

It may be that CF7 works like the Myarc controller or maybe completely differently from either one.

 

I do know the top 6 bytes at >3FFA – >3FFF are expected by the CF7 to be in that spot. See this from Jaime's CFMGR.S source code:

VDSK1      EQU     >3FFA
VDSK2      EQU     >3FFC
VDSK3      EQU     >3FFE 

I don't know about the 2 bytes at >3FF8 – >3FF9; but, I would think they are fixed, as well. And, you may be right that the CF7 indexes from the top of VRAM.

 

...lee

[senior_falcon]

Good info! I think TML clears out the memory above the buffers to >3FFF. Will check that tonight and modify if needed.

[+arcadeshopper]

I have a CF7+ and have not had any problems myself, then again my use these days is generally limited to running F18A test programs from the E/A cart. However, it looks like this is panning out to be a slight PEB vs. CF7+/Nanapeb difference.

 

The OLDER ones don't have any issues.. It's the newer models that I have seen the problem with. (com1, v2 etc)