senior_falcon

I included APERTURE, by Adamantyr with the XB game developer's package, and use it as an example of how to compile a program. I did not ask for permission to do this, and now realize that I should have done so. If this is a problem then I will remove it and substitute something else.

Don't know why that would be a problem. Can you PM the program to me along with a description of where the problem lies. (edit) Also, does this happen when running from XB256, when compiled, or both?

I would understand that bit 0 is the first of the four most significant bits, and bit 3 is the last. Is that correct, or am I thinking in reverse? (Edit) Below is from the 9918 VDP guide. Unlike the description in the E/A manual, here there is no ambiguity as to which bit should be set. "The fourth byte in the Sprite Attribute Table entry performs two functions. The lower four bits(nibble) define the sprite color, which can be any of the 16 available VDP colors. The MSB is the Early Clock bit, which shifts the horizontal position of the sprite to the left 32 pixels (whenset high). The remaining three bits are unused and should be set to 0."

"The four most-significant bits in the fourth byte control the early clock of the sprite. If the last of these four bits is 0, the early clock is off. Then the sprite's location is its upper left^iand comer, and it fades in and out on the right edge of the screen. If the last of these four bits is 1, the early clock is on. Then the sprite's location is shifted 32 pixels to the lefti allowing it to fade in and out on the left edge of the screen" Above is what the E/A manual says. In my code I read the color byte, then ORI R1,>9000 and then write it back to the VDP. This does not accord with the E/A manual. My notes say this is necessary for compatibility with Win994a. It does set the last of the four most significant bits, as the E/A manual says, but it also sets the first. It doesn't seem to cause any problems.

Here is a short program that shows what you want to do. The video shows it first running in XB and you will see a slight flicker when the sprite wraps around. The compiled version does not do this. A revised version of RUNTIME4 is below the program. This has the proper code for EARLYC. The previous version had an older version of EARLYC that combined the sprite number and the sprite color. That is not done in XB256 and now the compiled version matches that behavior. 5 CALL MAGNIFY(4) 6 ECO=0 10 CALL SPRITE(#1,65,16,100,100,0,5) 20 CALL POSITION(#1,X,Y) 40 IF Y<2 AND ECO=0 THEN CALL LINK("EARLYC",1):: ECO=1 :: GOTO 20 50 IF Y>33 AND ECO=1 THEN CALL LOCATE(#1,X,Y-32):: ECO=0 :: CALL COLOR(#1,16):: GOTO 20 60 GOTO 20 (Edit) In line 50, the CALL COLOR(#1,16) is there to turn off the sprite early clock. In code that will be compiled, there is another way to turn the early clock on/off. There is no limit check on CALL COLOR, so if you add 144 to the color it will turn the early clock on. According to the E/A manual it only needs to be 128, but my notes say it must be 144 to work in Win99/4a, and that change seems to cause no problems on other simulators. CALL COLOR(#1,160) !early clock on CALL COLOR(#1,16) !early clock off RUNTIME4.TXT

I will have a short demo program for you soon, but in testing it, I found that CALL LINK("EARLYC",X) does not work properly in the compiler. I don't see how the code I wrote makes any sense. So I will study that until I have an answer, and then will post it. There is another way to do it that works fine compiled, but I want both ways to work.

In theory, a word processor could be written using the jailbreak method to start up an assembly language word processor that runs in 40 columns. No cartridge required; this would need nothing more than a console and tape player. You would load the program from the tape player, and then load or create the document, which can then be saved to tape when desired. As a rough estimate, it might use about 5K for the program (depending on the bells and whistles), which would leave about 8K for the document. (About 3 or 4 pages) As far as I know, this does not exist, but it should be possible. The fly in the ointment is that a bare console has no way to send text to a printer. That requires some kind of expansion system, although I understand there was a cart that could send text to a printer.

It's pretty clear that your line drawing routine is quite a bit better than the TI one!!! Guess I picked the wrong one to copy.

Almost right. BASIC and XB think the screen is from row 1 to row 24 and col 1 to col 32. But the VDP thinks the screen is from row 0 to row 23 and col 0 to col 31. So one additional instruction must be added: For HCHAR or VCHAR 90 LOC=LOC+33 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 or 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 120 ROW=ROW+1::COL=COL+1 Just to make it interesting, DISPLAY AT starts two columns over. DISPLAY AT(3,1):"*" is the same as CALL HCHAR(3,3,42) So for DISPLAY AT: 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 120 ROW=ROW+1::COL=COL-1

Yes, but I am pretty sure I would not be able to find it. As I remember, I adapted the line plotting routine from Lines for The Missing Link. I can extract that and see how it compares. There are some things that make it a little slower in The Missing Link than it would be when running from assembly.

That sounds like a really interesting concept. Good luck! I would love to see this go from concept to reality.

Very funny concept, and as usual, well executed. The one question it leaves unanswered is this: is the toilet paper mounted so it goes over or under the roll? Inquiring minds want to know...

Here's another datapoint - Lines in Cortex BASIC running out of FinalGrom on a 16-bit console - so some of Cortex is running from cartridge space. Significantly slower than running purely out of 16-bit RAM, looking to me like the line drawing routine runs out of 8-bit cartridge space in this setup. Actually, the debugger shows the line drawing routine running from the 32K memory. There are things done in the cartridge rom, which probably involve processing the X and Y points

Your console has the 32K memory on the 16 bit bus. Since 2/3 of Cortex basic is in the 32K memory, it would be interesting to see how lines runs in that environment. (I don't know where the plot routine is. Would be easy to find out with the debugger, but I am at work.) Oops - sorry. I see you posted that back on August 3rd.