Jump to content

Alfred

Members
  • Content Count

    792
  • Joined

  • Last visited

  • Days Won

    1

Alfred last won the day on September 30 2018

Alfred had the most liked content!

Community Reputation

576 Excellent

About Alfred

Profile Information

  • Gender
    Male
  • Location
    Elmwood, Ontario

Recent Profile Visitors

8,974 profile views
  1. Yeah, it's not clear why that works. Here are the relevant parts from the cartridge: ; <def dcl> ..:= DEFINE <def list> ; <def list> ..:= <def list> , <def> | <def> ; <def> ..:= <id> = <str const> dcl200 jsr mkent ; DEFINE - create name ldy #0 lda #defid ; store data type sta (props),y jsr getnxt cmp #eqlid ; always have to have bne dclerr ; an assign for define lda nxttkn cmp #quote bne dclerr ldy #0 lda (symtab),y clc adc #2 ; real size + EOL jsr stincr ; save string from overwrite jsr getnxt ; string itself jsr getnxt ; dummy string jsr getnxt cmp #comma ; look for more dcl210 bne dcl140 ; whoops, go back some beq dcl200 dclerr ldy #dcler jmp splerr So the cart is trying to pull three tokens following the "=", which I don't quite understand. The first getnxt will be to pull the first quote forward to enable the string getter to build the string token: ; LexStr() ; -------- lexstr lda token cmp #quote beq pback ; zap local st lda #0 sta arg9 lxs010 jsr nxtchr inc arg9 beq lxs030 ; string too long cmp #'" beq lxs040 lxs020 ldy arg9 sta (symtab),y lda chan bpl lxs010 ; if not EOF lxs030 ldy #strer jmp splerr lxs040 jsr nxtchr cmp #'" beq lxs020 ; " in string ; end of string ldy arg9 lda #eol sta (symtab),y dey tya ldy #0 sta (symtab),y ; save size lda symtab ldx symtab+1 ldy choff ; PUT THE 2 QUOTES BACK dey jmp ldig2 You can see it is watching for embedded quotes, which appear to be back to back. I guess the space breaks the two quote sequence, allowing the final quote to close the string. I think the three quotes together would have given you an embedded pair of quotes in the final string which probably would break the expander. Good find though.
  2. What zbyti says. The value of DEFINE is a string constant and cannot be an actual string. You would need to define a string variable separately and then use DEFINE to substitute it.
  3. Yes the extensions disks are tightly coupled with the cartridge. There are two build files for BASIC XE, one builds the cart and the other builds the extensions. Basically the extensions build has .OPT NO OBJ for all the included cartridge source files. Now it may be happenstance that say the 4.1 extensions will work with a 4.0 carttridge, I don't know if the vector table in $CCxx is fixed or not. I would assume that you must have the matching extensions if only because it was built with the addresses in the same cart version, and those are very unlikely to be the same across versions. I know that the 4.2 cartridge is very different than the 4.1 just in the first 100 bytes, so I would not expect the 4.2 extensions to work at all with 4.1. Unfortunately we don't have the source for 4.1 so it would be very time consuming to see what was changed between 4.1 and 4.2, it would be a massive disassembly. I think the listing for 4.2 is 400KB or so. Yes, 4.2 extensions completely breaks the 4.2 cartridge. I don't know if it's because it overlays the jump table improperly or if the code itself is bugged.
  4. Yes, I really prefer my IBM Type-M keyboards, all model 42H1292. Bought a bunch at a flea market years ago, $5 each. On my second one now. Anywhoo, BASIC XE 4.1 AFAIK is completely stable and usable on any platform. The extensions work, with the exception of the CALL/PROC bug I mentioned previously. Symptoms of the bug are the program randomly stops, return variables may be set to zero, and sometimes the display will blitz out. 4.2 I did not test extensively because without the extensions it's not all that useful. The cart seems to work correctly, but as soon as you load the 4.2 extensions, it fails to function. I don't see any reference to OSS carts specifically on the XFormer 10 page, it just says 16KB carts, but Mihocka's not an idiot (at least he didn't used to be when I met him) so presumably they should work.
  5. Should work on anything, the code is good except for Proc/Call. 4.2 I think the cart is ok, it’s the extensions are bugged. Now I can’t say specifically about XFormer, but if it supports OSS carts, 4.1 should work fine.
  6. 4.2 extensions are broken. Just loading them breaks Basic XE 4.2. I haven’t looked into why. 4.1 with the 4.1 extensions disk works. 4.1 Proc/Call is broken, I think Call has to be first element in a statement, it can’t follow anything IIRC.
  7. In the extra devices, it's not required that the device server is written in Python, correct ?
  8. No, it is, when the comparison is with a memory mapped display. Perhaps, I should amend that to all E: devices which scroll, watching them redraw a full display 40 or 80 columns is like watching paint dry. Apparently we differ in our sense of the passing of time. I have a near zero tolerance for many things these days, and non-zero screen redraw time is certainly one of them, which is why when I get some time I am porting that damned Action! editor to the VBXE. Either that or my port of SPF/PC, but I haven't solved the NewLine/Enter key problem for that one.
  9. Geeze, I'm well aware of how the Action! editor works. I'm merely pointing out that you insisting that the XEP80 is as fast as a local memory display for editing (like the Action! editor) is simply not true. For full screen editing without delay, the only choices I see today are Antic or VBXE. E: solutions are not viable to me, no matter how fast, they don't beat a memory mapped display, period. Yes, Avery's custom XEP driver is fast (I looked at it the other night) but MAC/65 doesn't paginate anywhere near as fast using it as the Action! editor does with its memory mapped display. Yes, that fast driver isn't molasses compared to the stock E: but compared to a memory mapped display, it is.
  10. Ok, enough. Load up the Action! editor, and load a couple pages of text. Page Down. Instantaneous. Now copy your wall of text to the XEP-80 E:, see how long it takes to go from top of screen to bottom. Not instantaneous. As a DOS CLI display, XEP-80 is fine. As a paginating display. it's SLOW. Now if there is some secret mode that grants you access to the memory in the XEP-80 or otherwise lets it paginate at lightspeed, then I might change my mind. For *full screen code editing* an XEP-80 is not a good choice, IMNSHO. For the MAC/65 editor, I'm sure it's swell, but I quit using that editor 15 years ago.
  11. The XEP-80 is a dead end. It's good for a DOS CLI display and that's about it. You want good 80 column editing, it needs to be a VBXE. Watching the XEP-80 scroll a full screen of 80 column text is like watching paint dry.
  12. So where's the source code for this TNFS server that Fujinet works with ? Any reason an 8-bit can't also be a host, or it's limited to the pc platform ? I get that there's issues with libraries for things like HTTP support, but surely another 8 bit could be a simple file server.
  13. In KMK's example program, it looks like he uses the blitter to scroll. Is there any reason to do that, besides as a code example, rather than just block moving memory ? It adds some complexity for I'm not sure what benefit, it's not like a code editor needs that kind of high performance ?
  14. This. I think people seriously overestimate the number of good systems level coders available for things like this. Want to know why there isn’t a version of say Action! that runs on Rapidus and has a VBXE display, try looking in the mirror and asking why *you* haven’t done it. I bet there isn’t ten guys like Drac030 on here and they already have their own pet projects. Then, after you’ve written a few hundred thousand lines of assembly language, you tend to lose a little of the old enthusiasm. I get that lots of people just want to load their multicart and Joust all day, and that’s great. But before you bemoan the lack of a decent version of SPF/PC for the Atari you need to understand that unless somebody *you* steps up and does something, it ain’t going to happen. The days of a commercial software house writing code for this platform are long gone. KMK is busy, you’re going to have to find someone else. And not Rybags either, I think he’s busy too.
×
×
  • Create New...