Jump to content

Lee Stewart

+AtariAge Subscriber
  • Posts

    5,820
  • Joined

  • Last visited

Everything posted by Lee Stewart

  1. Wow! This took a bit of head scratching and code wizardry(?). Everything related to graphics mode switching seems to be working now. The 64-column editor also works fine. Here is the current beta: fbForth300_8_Na.bin Gettin’ tighter!: bank 0: 162 bytes bank 1: 112 bytes bank 2: 118 bytes bank 3: 118 bytes ...lee fbForth300_8.bin
  2. Indeed, if the entire 4 KiB block at >3000..>3FFF is unused by the p-system, using >3000 (SAMS register address = >4004) as your only 4 KiB paging address, you are good for a single 4 KiB SAMS page window. ...lee
  3. The problem with invoking the 64-column editor does, indeed, involve graphics mode switching. When the graphics mode is switched from non-bitmap modes (TEXT,TEXT80,GRAPHICS,MULTI) to bitmap modes (GRAPHICS2,SPLIT,SPLIT2) or vice versa, the system PABs (1user font file, 2 blocks files) are moved. The problem with the move is that the VRAM buffer address in each PAB does not get updated, so all hell breaks loose when the EDIT word is invoked with no intervening USEBFL (Use Blocks File). There may be one other VRAM location change that needs to be made, as well. I may be able to split COLD into more than one routine such that a part could be invoked by the mode change code to make everything better without too much code bloat. We’ll see .... ...lee
  4. We have enjoyed it since December 1. Returning to Maryland to, likely, rain April 2. ...lee
  5. OK...I am pretty much done with the Chapter-8 File I/O changes for the new DSRLNK. I also have working DIR and CAT utilities for the new FBLOCKS. I have been puzzling over what broke the 64-column editor and am reasonably sure it has to do with graphics mode switching and blocks I/O code. I did make changes to both and undoubtedly broke something. I did discover that, if I switch to Split mode before invoking the 64-column editor, it works. Exiting the editor shows issues, as well. I need to work through the mode-changing and blocks I/O code to shake out the bugs—too many balls in the air at once, I’m afraid! Aside from bug fixing (may not get done until after return from Florida next week) and managing the DSRLNK changes for Alternate I/O (RS232 card) for KEY and EMIT (easy) , I am nearly done with the cartridge code for fbForth 3.0. After I run down the bugs in recent code changes exposed by the 64-column editor, I will start knocking down the updates for FBLOCKS. Meanwhile, here is the current beta: fbForth300_8_Ma.bin Current remaining cartridge space (some improvement! ) bank 0: 162 bytes bank 1: 102 bytes bank 2: 184 bytes bank 3: 118 bytes ...lee
  6. It should be there until you turn off the computer. Also, there is really no reason to turn off the mapper unless you really want the start-up, transparent mode. I mentioned before that, once initialized in fbForth, the mapper is never turned off. ...lee
  7. Yeah...any blocks with DSRLNK calls must be updated before they will run properly. I am nearly done with DSRLNK updates to the fbForth 3.0 cartridge. I will then get after FBLOCKS. Thanks to you and @TheBF for your tests! ...lee
  8. The current version of FBLOCKS is 17LUL2023 and definitely not up to date. I have to update any blocks that use DSRLNK. EDT is the main word in the 64-column editor. EDIT is redefined to run EDT in the EDITOR2 vocabulary. It does, indeed, run in SPLIT mode. ...lee
  9. I am coming from the highest possible SAMS size (32 MiB) down. The first time that I find the test location does not contain >994A, I know I have reached the highest mappable SAMS. You see, >994A should only ever exist in the initial location. If there is no SAMS, the test location will always show >994A. Once a successful mapping takes place, there is a different memory page swapped in that does not have >994A at the test location, hence the exit at that point. ...lee
  10. OK... I now have the new DSRLNK working for all words/functions (blocks I/O, FILES word, Font Editor) except the high-level File words (Chapter 8 of the manual) and the alternate keyboard/display I/O. If you want to try it out, here is the beta: fbForth300_8La.bin Oh...I should add that current free space is down to bank 0: 116 bytes bank 1: 92 bytes bank 2: 172 bytes bank 3: 118 bytes ...lee
  11. Sorry. Actually mapping is on before that code is run. I forgot to indicate that the first thing fbForth does is to initialize SAMS, whether or not it is present. You actually should not need to do this if you want the default mapping of page 2 to >2000, 3 to >3000, ..., >0F to >F000. At that point, I enable mapping (SBO 1) and never disable it. The code I posted is after this, so mapping is enabled. You are correct. I never write to the test page. If SAMS is operational at the page I test, it should not have the >994A value. If it does, there is either no SAMS or the attempted page swap failed because >994A should only ever exist in the original/initialized RAM location. Also, you only turn the card on for the brief moment you want to write to the SAMS registers. The card does not need to be on when you are writing to the actual mapped-in memory! Mapping, however, obviously needs to be enabled. ...lee
  12. Here is how I do it in fbForth (note that only pages are considered in the comments, i.e., the number representing bank:page is the number referred to below as “page” for simplicity): ...lee
  13. As I last posted, I did read back a SAMS register via MOV and received the page# in the MSB and the bank# in the LSB. The Classic99 debugger did not complain to me. My fbForth assembler code is HEX ASM: SAMSRD ( reg -- val ) *SP R1 MOV, \ get SAMS register# (0..Fh) from stack R1 1 SLA, \ *2 (SAMS regs on even address boundaries) R1 4000 AI, \ compute SAMS register address R12 1E00 LI, \ load CRU of SAMS card 0 SBO, \ turn on SAMS card *R1 *SP MOV, \ read SAMS register 0 SBZ, \ turn off SAMS card ;ASM which is the same as this ALC: MOV *SP,R1 SP=R9..has address of current SAMS reg# SLA R1,1 *2 (SAMS regs on even address boundaries) AI R1,>4000 compute SAMS register address LI R12,>1E00 load CRU of SAMS card SBO 0 turn on SAMS card MOV *R1,*SP read SAMS register SBZ 0 turn off SAMS card ...lee
  14. @FALCOR4 confirmed that real hardware does not store the bank#. You should just ignore the LSB returned because it will be a repeat of the page#. On the other hand, I checked Classic99 and it does return the bank# in the LSB. For consistency with hardware, it really should not do that. Oh, well. ...lee
  15. I should add that reading a SAMS register only gets you the page# of the bank:page scenario, which would be why the following instruction surely failed in Classic99: c r1,@401eh ;if match then card present This is because the page# is stored in the SAMS register, but the bank# affects only the latches on the SAMS card. ...lee
  16. Bruce Harrison’s code works fine up to 1 MiB SAMS, but fails above that due, I think, to a misunderstanding, early on, of how the SAMS card operates. Having the same value in both bytes of the word copied to the SAMS registers works up to 1 MiB because only one byte matters (MSB, actually). Always putting the same value in the LSB as the MSB means you don’t need to worry about which byte needs the value. Above 1 MiB, you need to treat SAMS properly, because, now, both bytes are important. There are a couple of ways to think about this: (1) only pages from 0 to the maximum page (>FF for 1 MiB, >1FFF for 32 MiB as in Classic99) or (2) banks and pages, with each bank having 256 pages. Either way, the word copied to a SAMS register is the same. Using the bank:page scenario, you can put the zero-based bank# in the MSB and the zero-based page# of that bank in the LSB for ease of coding/understanding and swap the bytes just before copying to a SAMS register. Or you can put the bank# in the LSB and that bank’s page# in the MSB and copy to a SAMS register without swapping bytes. When your code copies >0101 to a SAMS register, you are invoking page 1 of bank 1. For 1 MiB SAMS, this is really page 1 of bank 0 because only bank 0 exists, i.e., the LSB is ignored. However, for Classic99, you actually are invoking bank 1, which was not your intention. It is for this reason, I never use the Harrison scenario, even when it is safe up to 1 MiB—it just is bad practice. The following has a better chance of working in Classic99 (changes to initial value and increment of R1): ;routines for sams card access ;walid maalouli ;march 2024 .func samsinit ;initialize the sams card and verify card is present ;returns 0 for absent and 1 for present ;adapted from routine by bruce harrison (rip) ;usage: status := samsinit .def procret,pmeret,pcodeon,pcodoff mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn card on li r1,0ff00h li r0,4000h ;start address of sams registers nxtpage ai r1,0100h ;increment page number starting at 0 mov r1,*r0+ ;load page number into sams register ci r0,4020h ;beyond last register (401eh)? jlt nxtpage c r1,@401eh ;if match then card present jne nocard li r2,1 jmp endinit nocard clr r2 endinit mov r2,*r10 ;place card indicator on return stack sbz 0 ;turn sams card off bl @pcodeon mov @procret,r11 b *r11 pcodeon li r12,1f00h ;activate the pcode card sbo 0 mov @pmeret,r12 ;restore the pme pointer b *r11 pcodoff mov r12,@pmeret ;save the pme pointer li r12,1f00h ;deactivate the pcode card sbz 0 b *r11 pmeret .word procret .word .end ...lee
  17. I now have a working Miller-Warren-Stewart DSRLNK! See post #1 for the latest version. It now stands at 290 bytes. There may be a few bytes I could save somewhere, but I think I am done with that effort. It is 70 bytes less than the Bagnaresi-Sullivan-Stewart DSRLNK, so I think I will continue using the Miller-Warren-Stewart version. I should note one error I found in the original Miller-Warren code. The COC instruction in the routine cannot possibly work as intended: COC @GSTAT,R8 else, test CND bit for Link Error (00) The source operand (a general address) is the mask for testing bits of the destination operand (must be a register). The mask is >2000, which is in R8 (original was R12, but I had to use a different register), should be the source operand. But, since the destination operand must be a register, @GSTAT cannot be that operand. Since R4 was not used after return from executing the DSR/subprogram, I copied the contents of GSTAT to R4 and used R4 as the destination operand: MOV @GSTAT,R4 copy GPL status byte for error processing * . * . * . COC R8,R4 else, test CND bit of GSTAT$ for Link Error (00) Now it properly tests R4 (GSTAT copy) for the single bit (>2000) in the R8 mask. Again, the latest code for the Miller-Warren-Stewart DSRLNK is in post #1. ...lee
  18. Usually, 1300 is the CRU address for both RS232/1 and RS232/2 and 1500 is the CRU address for RS232/3 and RS232/4. ...lee
  19. Stephen Shaw is @blackbox here. ...lee
  20. Surely you intended SRL R6,8 ...lee 😄
  21. Could be @lucien2, but check the first few posts of @Willsy opened with saying he had coded a TI Basic version, but I don’t know whether he ever posted it. ...lee
  22. In getbyte, if the MSB of R6 is ignored, this is not a problem, but, as far as I can tell, the MSB of R6 is indeterminate unless it has been cleared before invoking the procedure. ...lee
  23. This is what Thierry Nouspikel says: The controller card comprises a 8192 bytes (>2000) ROM that contains a power-up subroutine, four DSR for high-level file access and many subprograms for low- or mid- or high-level disk access. As usual with peripheral cards, that ROM appears at >4000-5FFF when CRU bit 0 is set to one for that card. Note that the controller's register map at >5FF0-5FFF, thus the last 16 bytes of the ROM cannot be accessed. You'll find a commented disassembly listing of the whole ROM on my download page (warning: it's written in an ugly programming style). ...lee
  24. See latest beta in this post. ...lee
  25. While working on my new DSRLNK, I had improved (I think) VRAM reads to use fewer instructions than I had used previously, so I thought I should review other ALC in the fbForth kernel for the same improvements. While doing so, I discovered a bug I had introduced into SPRGET while trying to fix a previous bug related to how a sprite’s y value is stored in the Sprite Attribute Table. The bugs and their ultimate fix are described in the excerpt from my fbForth 3.0 TODO list in the spoiler: Here is the latest beta with the fix: fbForth300_8_Ka.bin <<< Happy now, Bob (@atrax27407)? >>> ...lee
×
×
  • Create New...