Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

flashjazzcat

Members
 View Profile  See their activity

  • Content Count

    17,025

  • Joined

  • Last visited

  • Days Won

    25

Posts posted by flashjazzcat

  1. Posted

    This program:

     

    http://drac030.krap.pl/sio2bsd.tar.gz

     

    can create and handle 32 MB ATR images. You have to configure and compile it yourself, though (it is written for FreeBSD). Then you can use them from real Atari by means of SIO2PC or something like that.

     

    Accessing "H:" (or any CIO device) directly from the SDX command processor is not currently possible. Some device driver is planned to address this issue, but, since supporting emulators is rather far on our priority list (if it is there at all), it has not been yet written.

     

    Thanks for the info! I'll give that utility a try and let you know how I get on. It would be useful, especially since the H: device is a bit of a dead-end for me at the moment. ;)

    • Like 1

  3. Posted · Edited by flashjazzcat

    I believe you will need a device that actually has 512 sectors, and I'd be suprised if the H: device in Atari800(Win+) emulates 512 byte sectors. The H: device is more of a way to access your PC files though, so maybe the disk drive emulation is where you would look for 512 byte 32MB ATR support.

     

    From:

    http://www.atarimax.com/jindroush.atari.org/afmtatr.html

     

    It looks like sector size of the ATR format is either $80 or $100, but since it's two bytes anyway, $200 should work. Whether current tools (like APE and the emulators) will support that is another story.

     

    Thanks. I understand that the H: device would offer potentially unlimited storage and is entitrely separate from the 512 byte sector issue... I probably didn't word the question too well in that respect. I meant to point out that I want to try and create a 32MB ATR image under emulation. Clearly the way to do this is with 65535 sectors at 512 bytes per sector, and I wanted to experiment with the 512 byte sector buffers in the latest version of SpartaDOS. It never occured to me that Atari800Win and variants thereof might themselves have a sector size limitation, even if such an ATR image could be created by another utility. :(

     

    This brings me back to another part of my original query: Since the H: device is indeed an easier way to create large storage devices under emulation, is there a way to address hard disks H1:, H2: etc using SpartaDOS X? It seems to me there is no obvious way to reference this drive ID from the SpartaDOS X command processor.

    • Like 1

  4. Posted

    Is there a utility which allows the creation of 512 byte sector ATR files? I want to try and create a 32MB disk image to use with SpartaDOS X. Everything I've tried is limited to 256 byte sectors. I'd use a virtual hard disk (H:) but I'm unclear as to how you're meant to reference such a disk ID from the SpartaDOS command line (surely H: is translated to D8:?).

    • Like 1

  7. Posted

    Finally got the manual for the MA65 Assembler written up so here's a disk image with the Assembler, source code and text editor:

     

    MA65.zip

     

    And this is the manual for the assembler:

     

    MA65_Macro_Assembler.pdf

     

    There are a couple of things I'd like to add to the assembler but the source code is there for others who want to have a look. Ideas for imporovement, bug reports, etc, welcome as usual.

     

    Enjoy! :)

    • Like 2

  8. Posted

    I have to say that I REALLY love your little SpartaDOS EDITor program! It seems to have more features than anything I have used up to now.

     

    Great work!

     

    Glad you like it! I'm only sorry I appear not to have the source code among my converted disks :(

     

    Hey Jonathan,

     

    when I use the flash.com utility the cursor starts blinking only after the first keystroke. Is that by design or is there something wrong with my configuration?

     

    grtx,

    \twh

     

    No, it's not by design. I've been testing the FLASH.COM program in an emulator and it does seem a bit flaky, although I haven't encountered the problem of the cursor not flashing until the first keystroke. I'll try and look into it...

     

    Hey Jonathan,

     

    one more question. What is your "The MA65 Macro Assembler for SpartaDOS" ? A command line enabled MAC65? I wish I could use my favourite text editor (like edit or you tools) and build the artifacts using a "make" kind of utility in SpartaDOS. That would be nice :)

     

    grtx,

    \twh

     

    Yes, MA65 is a command-line enabled macro assembler and it should enable you to do everything you want. There's also an enhanced version of EDIT called "XEDIT" which was used to write the source code for The Last Word. I'll release both programs tomorrow. :)

  10. Posted · Edited by flashjazzcat

    This can be done much safer with RTCLOCK:

     

    	lda rtclock+2
wait:
cmp rtclock+2
beq wait

     

    And it is yet safer to load ANTIC/GTIA registers through shadows. The loop is not necessary then.

     

    Yes, I can see how that would work well. The VCOUNT routine works, anyway, although your code is a byte shorter! I used the wait routine to synchronise enabling and disabling of the display list interrupt (NMIEN) with the vertical blank. It was a small issue but seemed to get rid of very occasional screen glitches.

     

    I have a attempted to convert the LW source code (all 8,000 lines of it) to a format compatible with the MADS or ATASM assemblers, but have encountered numerous problems making the MA65 listing compatible with either. MA65 has an idiosyncratic source code format (although it's not alone), and while I had some success making it work on a cross-assembler, getting rid of all the 'illegal' string characters that MA65 allows is proving a pain. I might write a program to convert the source code to MAC/65 native format, and release it like that. In any case, however, I'll be releasing my assembler along with the source code. My immediate plans are to implement the auto-RAM sensing routines, and in the future I'd like to release a special SpartaDOS X only version, which takes advantage of RAM under the OS to allow for a larger macro buffer and main text buffer, permanent reinstatement of the icon menu, two extra lines of text on the screen, an even better disk utility menu, and a programmer's mode, which displays line counts and expanded tabs on the screen.

  11. Posted · Edited by flashjazzcat

    The fixed version loads without problems, thank you!

     

    It may be interesting, what was actually going on:

    - 6502: $82 is an "illegal code", which is a kind of NOP skipping next byte ($9B here); so nothing really bad happens, the program continues normally

    - 65C816: $82 is an opcode for BRL instruction (unconditional Branch Long), which takes 2-byte argument (branch offset); the following two bytes form an offset of $D09B (negative number), so the execution continues at some place in memory with undetermined contents, making a system crash.

     

    Yes - that's exactly correct. The code segment in question is the routine that was originally causing the program to hang on NTSC machines:

     

    VBWAIT

    LDA VCOUNT

    CMP #$9B

    BNE VBWAIT

    RTS

     

    Its purpose was simply to wait until a complete screen frame had been drawn. However, on an NTSC Atari, VCOUNT never reaches $9B, so the program went into an endless loop. My fix was to simply replace $9B with $82. There are two instances of this code in the program; however, in one instance I clearly overwrote the CMP op-code with $82 by accident. This had the deceptive effect of fixing the NTSC bug, because the missing CMP op-code meant that any non zero value in VCOUNT would end the loop on a 6502 machine. Not so with the 65C816...

     

    Well done! :)

  13. Posted

    I deliberately avoided using 65C02 opcodes or any "illegal" instructions.
    Ok, I think I found the cause :)

    Look at the code which is loaded at address $3000-$303A and which seems to change the display list. You put there a byte which does not correspond to any 6502 instruction. It is $82 just after LDA VCOUNT. I changed it to a NOP (as well as the following $9B) and the program now loads without problems.

     

    Well done and thanks! This is a bug that must have been introduced when I implemented the NTSC fix. I thought I'd changed the $9B to $82 with a sector editor but obviously I hit the wrong byte. :ponder:

     

    I'll recompile the altered code now and upload a fixed version. Brilliant work!

  14. Posted · Edited by flashjazzcat

    To be more precise: the only config that lets me see the main editor screen on my 65816 system is with extended memory switched off and SDX enabled. This does not mean that the editor works ok is this setup. If I load the program from DOS 2.5, it just crash during loading (no logo shown). My friend who also has an 65816 equipped system wasn't able to run the program too.

    I tried the same with a stock 130XE and everything looked fine. This make me suspect that the 65816 is a concern here. Do you use any of the "undocumented" opcodes ? In 65816 they all do a NOP.

     

    I deliberately avoided using 65C02 opcodes or any "illegal" instructions. I'm inclined to think there's a memory conflict with the 65816 OS. LW wipes out the entire upper half of page zero, CASBUF in page 3, and all of pages 4, 5, and 6. Would that cause problems with any 65816 locations?

  16. Posted · Edited by flashjazzcat

    That's cool. I'd love to see them added. I wouldn't mine losing a line or two to have them. How did you work the icons? was there mouse support or did you step through them with a key?

     

    Allan

     

    There was never any mouse support (I never had a mouse), but the add-in could be easily modified to handle mouse input. As it stands, you invoke the icons with <CTRL+T> and use the left and right cursor to move and <Return> to select. You don't lose any screen space because they fit in the two-line status area. Try them here:

     

    LWADDINS.zip

     

    Just load them with <SHIFT+CTRL+M> and call up with <CTRL+T>. There are a few add-ins: two versions of the icons, a sort routine, a calculator, and more... documentation will follow soon. :)

  17. Posted

    Interesting: LW uses NO OS calls whatsoever, apart from calls to DOS via CIOV. It uses no FP, screen or keyboard handler calls, but DOES reference the OS keyboard lookup table if I recall correctly.

     

    How far does the program get when running on a 65C816 system? I'd be interested in debugging it. :)

     

    The keyboard definition table is separate problem. The LW should definitely reference it through the keydefp, not directly.

     

    As far as I tried, the LW does not so far, it simply hangs as soon as it is loaded. Nothing changes on the screen. The PC is in some weird place in ROM. trub says that the LW works when one disables the memory extension. This may be anything, e.g. a conflict with SpartaDOS X (which resides in one of the banks).

     

    Interesting about LW working when the memory extension is disabled: that certainly offers a clue. Have just been reading through the docs for the 65C816 XL/XE OS Revision 65C816 OS but I haven't seen any obvious conflicts yet.

     

    I've just checked the source code and LW does indeed reference the keyboard table directly at $FB51, so if it isn't still there, it isn't going to work. I'll use the KEYDEF pointer in subsequent revisions.

  18. Posted · Edited by flashjazzcat

    The LW does not work on the 65C816.

     

    I don't know a lot about this chip. How can we go about finding out why LW doesn't work with it?

     

    It should work as long as no illegal 6502 opcodes are used. Also, it should work with the 65C816 dedicated OS as long as no illegal OS calls are used (illegal = everything outside the $E400-$E48C and $D800-$DFFF).

     

    Interesting: LW uses NO OS calls whatsoever, apart from calls to DOS via CIOV. It uses no FP, screen or keyboard handler calls, but DOES reference the OS keyboard lookup table if I recall correctly.

     

    How far does the program get when running on a 65C816 system? I'd be interested in debugging it. :)

  19. Posted · Edited by flashjazzcat

    Very impressive Manual. Thanks, This will be a great help for using LW. :)

     

    A small typo I noticed.

     

    9.6.2 SPARTADOS X MEMORY CONFIGURATIONS

    If you have a 130XE or other expanded RAM machine, you can achieve the largest possible paste bugger with LW by including in your CONFIG.SYS file the line:

     

    LOL! That's a good one! The Paste Bugger feature was removed in version 1.6 :D

     

    Thanks for the corrections: I've spotted some other mistakes (such as the messed up heading half way down page 5-24 and a couple of obsolete references to icons which were removed after version 1.0). I'll give myself a chance to have another few read-throughs, then release a corrected version.

     

    I was wondering about that. I saw the references to icons and I thought cool but I don't remember seeing any. :)

     

    Allan

     

    Yeah - the icons were taken out to save space but there's an add-in for the current version which brings them back. I'll release it very shortly.

     

    post-21964-1228831648_thumb.png

     

    post-21964-1228831717_thumb.png

  21. Posted

    Very impressive Manual. Thanks, This will be a great help for using LW. :)

     

    A small typo I noticed.

     

    9.6.2 SPARTADOS X MEMORY CONFIGURATIONS

    If you have a 130XE or other expanded RAM machine, you can achieve the largest possible paste bugger with LW by including in your CONFIG.SYS file the line:

     

    LOL! That's a good one! The Paste Bugger feature was removed in version 1.6 :D

     

    Thanks for the corrections: I've spotted some other mistakes (such as the messed up heading half way down page 5-24 and a couple of obsolete references to icons which were removed after version 1.0). I'll give myself a chance to have another few read-throughs, then release a corrected version.

  23. Posted · Edited by flashjazzcat

    I've been working on this for a couple of days and I'm sure it'll have a few mistakes in it, but here it is:

     

    The Last Word 2.1 - User Manual

     

    The documentation that shipped on the Atari disk with the program was out of date and needed alteration - hopefully I've spotted all the changes. If anyone finds any mistakes or inconsistencies, please let me know so that I can work on a 'definitive' release of this documentation.

     

    Enjoy! :)

  24. Posted · Edited by flashjazzcat

    Source code and manual have just arrived by email. Can't wait to get started on this expanded memory recognition routine, but first I'll prep and upload the source and manual for download. I'll release the manual as an ATR disk image (it's in Last Word file format so offers a useful example of how to format text), but I'd also like to release a copy in PDF format (a la the SpartaDOS X Manual). The source code is in MA65 format (my own assembler) but I'll run it through some kind of filter to make a MAC/65 listing as well. I've also got XEDIT (a text editor for SpartaDOS which can handle 22K files), plus the source code for that, together with source code for MA65 and various SpartaDOS utilities. I hope to get everything released in the next few days.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...