Jump to content

Kchula-Rrit

New Members
  • Content Count

    42
  • Joined

  • Last visited

Community Reputation

38 Excellent

About Kchula-Rrit

  • Rank
    Space Invader

Recent Profile Visitors

91 profile views
  1. First, thanks for your assistance and the "extra eyeballs". I did the following: Got rid of the length byte on the filename, then set it to ten bytes padded with spaces, with a NULL byte. Changed MOV R8,@8350 to a MOVB. Tried running it with and without saving the GROM address. I did it because Tom Bentley did so in TCIO.C, figuring that he knew more about calling DSRs than I do. Is it plagiarism if you admit it? 8-) I still got all zeroes in my return values. Then, thinking it might be a mismatch between C and assembly (I would not be surprised if it is) I plugged values into the return variables on the assembly side and they printed OK. While I was prettying-up the code to possibly post it, I noticed several places where I forgot to include the ">" to make values hex instead of decimal. One of many bonehead mistakes I seem to make a lot. It still returns all zeroes, but now, after answering "N" to the "re-run C99" prompt, the computer locks up. Last time that happened I "fixed" it by re-formatting the "disk" in the NanoPEB and recompiling. I'll try that tonight. I'm running this with the E/A cartridge, with v5.1 of C99 with a date of 1994. The C part just prints the results. I can post the whole test program, but it's 180 lines. How would I do the scrolling blu-ish window thing that people do for code? K-R.
  2. I'm trying to use the Level 2 I/O function to get file information, but cannot seem to make it work. Using Thierry Nouspikel's information, I placed the following values in scratch-pad RAM: 0x834C = 2 (DSK2) 0x834D = 0 (Get file info) 0x834E = 0x2000 (filename = TEST;C) 0x8350 = 0x30 (0x8330 for returned info) 0x8356 = 0x2010 (start address for "command") I placed the following in VDP RAM: 0x2000 = 'TEST;C ' 0x2010 = 1 ("Command" length) 0x2011 = 0x14 (Get file info) Here's the code I used. I've fiddled with it, and gotten bleary-eyed from trying to read about how to make this thing work. I assume I'm doing something wrong, but just cannot figure out what. The part between the ellipsis(es) are the code I'm using. ... #asm * Clear STATUS byte. CLR R8 MOVB R8,@>837C * File is in DSK2. LI R8,>200 MOVB R8,@>834C * Zero means "get file info". CLR R8 MOVB R8,@>834D * Copy name to VDP RAM. LI R0,2000 * Save file-name pointer for DSR access. MOV R0,@>834E LI R1,MYNAME * File-name. LI R2,14 * Name length. BLWP @VMBW * Copy "get file info" command to VDP. LI R0,GETNFO LI R1,2010 * Save PAB pointer for DSR access. MOV R1,@>8356 LI R2,2 * "Command" name length. BLWP @VMBW * Place results at 0x8330. * C99 doc said this is unused by C99. LI R8,>30 MOV R8,@8350 * Set return status. 0 = success. SETO @RESULT MOVB @GRMRA,@MYGROM NOP MOVB @GRMRA,@MYGROM+1 DEC @MYGROM * Call DSR. BLWP @DSRLNK DATA 10 * If error, skip next instruction. JEQ ERROR * Call succeeded; set status to 0. INC @RESULT ERROR * Save dsr return code. SRL R0,8 MOV R0,@DSRERR * Restore GROM address. MOVB @MYGROM,@GRMWA NOP MOVB @MYGROM+1,@GRMWA ... * Saved GROM address. MYGROM BSS 2 * Test file. MYNAME BYTE 10 * Name length. * BYTE 6 * Name length. * TEXT 'DSK2.' TEXT 'TEST;C ' TEXT ' ' BYTE 0 EVEN GETNFO BYTE 1 * "name" length. BYTE >14 * "Get file info" routine. ... Any advice would be appreciated. K-R.
  3. Is that the "open directory" call, OPENing a file called 'DSKn." that I found in Nouspikel's Web site? Looking at Fred Kaal's site, I guess not. It's going to be more complicated... Sigh.
  4. I'm trying to use the NanoPEB DSR's STATUS command (op-code 9) to get file information. The status bits seem to look good, except for the FIXED/VARIABLE record-length bit. It always seems to be set, so my program thinks all files are VARIABLE record-length. Anyone else noticed similar behavior? Do other DSRs do the same thing? K-R.
  5. Nothing to do with the chip, but a funny coincidence. While going through some old papers yesterday I ran across a receipt from Unicorn Electronics for some 74612s I had ordered some years ago. Was wondering if they were still around; sounds like they are... K-R.
  6. Thanks; ZIP file is much easier and more compact. Glanced through the files, and will have to take a closer look. K-R.
  7. Thanks; ZIP file is much easier, and more compact. Glanced through the files, and will have to take a closer look. K-R.
  8. Accidentally posted in the Development forum, meant to put here but don't know if a posting can be moved or deleted... I just got a FinalGROM with the 4GB SD board. Before I do anything with it, I want to make a backup. Is it best to do an image backup, or just copy the files to a CD? An image backup will take 4GB, whereas it looks like a "file" backup will take roughly 100MB. Also, what debugger would be best for loading into the FinalGROM? My system has a NanoPEB-SIO v1 and an un-updated F18A, if that matters. K-R.
  9. POSTED IN THE WRONG SECTION- PLEASE IGNORE! I just got a FinalGROM with the 4GB SD board. Before I do anything with it, I want to make a backup. Is it best to do an image backup, or just copy the files to a CD? An image backup will take 4GB, whereas it looks like a "file" backup will take roughly 100MB. Also, what debugger would be best for loading into the FinalGROM? My system has a NanoPEB-SIO v1 and an un-updated F18A, if that matters. K-R.
  10. While investigating my runaway light show problem, I think I found a bug in TI's VMBW routine! Here's a disassembly of the VMBW routine: VMBW_START 2200 BL @VDP_SET_WRITE_ADDR >06A0,>223A '..":' 2200 VMBW_LOOP 2204 * Get data from caller's buffer, * pointed-to by R1 MS byte, * and send to VDP. MOVB *R1+,@VDPWD >D831,>8C00 '.1..' 2204 * Done? DEC R2 >0602 '..' 2208 * If not, send another byte. JNE BW >16FC '..' 220A * Return to caller. RTWP >0380 '..' 220C If R2 is zero (writing zero bytes to VDP) it will decrement before the check, sending 65536 bytes to the VDP, causing the "lights show," and trashing any PABs and other stuff. VMBR has the same "problem." Maybe not necessarily a bug; TI probably did not expect someone to send "nothing" to the VDP. K-R.
  11. If it recall correctly, I read on Thierry Nouspikel's site that Sectors 0 and 1 have the file-names. I assume you would have to look up the list of sectors for the particular file-name and read them one-by-one. K-R.
  12. In reference to my question about sending a zero-length record to NanoPEB, it finally occurred to me to use TIDir to look at source files I had transferred using TELCO XMODEM protocol. Lee Stewart said that a record is a length-byte followed by the data. I found several zero-bytes which correspond to blank lines in the source file. It seems that the E/A cartridge stores a blank line as a one-byte followed by a space. That makes sense. It would seem that my runaway program and the corresponding "light show" are either my program or the TCIO library. Looks like some more experiments are in order. It seems my little question has prompted a bit of a stir. 8-) K-R.
  13. I thought the PAB data buffer was required to be in VDP RAM, then the calling program does a VMBR to get the data into "normal" RAM. It just never occurred to me to try doing so. I tend to assume that the people who make these things that I use (C99, TCIO, etc.) are smarter than me and know what they're doing. Since I'm playing with the TCIO code already, I could try it. I have frequently thought of playing with DSRs but I worry about breaking equipment that I consider irreplaceable. Are TIs fairly bullet-proof in that respect? K-R.
  14. Here's my World Domination Console... The tangle of cables seems to be unavoidable. They go to the Win98 machine, the monitor, and the external power supplies, and the speaker. It's an unmodified console, except for the F18A, NanoPEB, and an external power supply. K-R
  15. Thanks for the answer. I don't really need 256-bytes, just curious if it could be done. I've seen setups where the data-length is stored in a byte, and a zero value meant 256 bytes. The "light show" I got would seem to confirm your idea that, for TCIO, a zero-length record is an error. I assumed it was a runaway VDP-write transfer that trashed the VDP setup tables. K-R.
×
×
  • Create New...