Jump to content

raster/c.p.u.

Members
  • Posts

    224
  • Joined

  • Last visited

Posts posted by raster/c.p.u.

  1. Hi all.

    I want apologize for dirty bug in my educational Intro1k for Forever Dirty Dozen demoparty.

    Thanks to Fandal, Eru and Fox, who are great pupils and alert me about redundant CLC instruction in dimension-Y part.

    So, there is corrected version (I hope :) ) called CI26.

    It has 1023 bytes. 1024 has original CI28 intro -1 redundant CLC instruction = 1023 bytes ;-)

    Greetings, raster/c.p.u.

    CI26.XEX

    post-3740-0-86025700-1300784986_thumb.png

    • Like 3
  2. There is one weird thing about the VTOC of the disk with FLOP magazine: it says its MyDOS format, but it is not. So SpartaDOS X (and probably MyDOS too, but I didn't check that) has a problem extracting files from the ATR with an ordinary copy. To fix that, get a disk editor (<commercial>Eddy is ideal</commercial>), go to sector $0168, change the value of the first byte to $02, and write the sector back. After that, the DOS will be able to read the disk so you can copy the game (and other files) to your harddisk for example.

     

    Hi.

    Hmm, I think it is "standard" DOS II+ behaviour.

    When I format disk to single (FS#), then there is $02 value in VTOC.

    If format is medium (FM#), there is $03 value.

    I check it in all the Flop magazines (28 to 53) and all of them has $03 there (for medium size).

    Greetz, raster/c.p.u.

  3. What does everybody else do about this problem? Do people just dump files onto the SD and not care about the order?

    Well, it looks like I'll just have to wipe the SD and manually copy each file in order... again.

    Hi. Yes, there is FAT file's ordering trouble as you wrote.

    SDrive hw can't sorts filenames because it hasn't memory for doing it.

    Atari SDrive control software could, but it would be very very slow because of reading whole directories (!) every time, no only 1 page (20 filenames).

    But there is one helpful function Control+F for searching (or Shift+characters). Please read the SDrive manual.

    Greetings, raster/c.p.u.

  4. Change your program

    15 POKE 41018,64:POKE 41019,164

    1110 EK=42048

    Then your videoram will be from $a440 (42048) with regular 4K boundary at $b000 (45056).

    (You can run state file in attachments, then break it and list the adjusted source.)

    hi8.zip

  5. Mathy, multijoy8 interface costs 3 euro including PCB and all parts required, if You want 4 port version of it - it would cost one euro less

    Stackable 4 port version will be more expensive than MultiJoy8, because there would have to be some additional electronic parts and additional two joy connectors for next multijoy. So, I think stackable MJ4 interface is nice and impressive idea, but it's not effective. ;)

  6. Not sure that I explained my question properly, but the answer is yes you can copy disc images from the sdrive to a real disc.

    Yes, of course.

    As well as you can read the files or any data from disc images activated in SDrive, you can also copy this files/data to other disc drives by some tools (file copy tools, sector copy tools, etc.). SDrive is one of Atari disc drives alike others. :)

  7. faccess_offset() calls mmcReadCached() before zeroing each sector. This call could be skipped, except for the first sector of ATR images (we need to keep the ATR header :-) and for the last sector. The sectors in between could be written directly. This would save some time and maybe we could stay below ~4 minutes.

    I'll have a closer look at the code and see if it's possible to squeeze the additional code into the firmware.

    Please, take care of changes in main R/W operations. We really don't want to meet some disasters with destroyed data. :ponder:

    Also I'm a bit afraid of source code lucidity with some special exceptions in main methods... ;)

  8. Hi.

    Another strange thing: When formatting with "/N" MyDos sends a percom put command to the SDrive and tries to configure it to standard 720 sectors SD/DD, but the SDrive responds with an OK (I had suspected to get an error here). Internally, the SDrive just marks the received percom config as invalid so it won't allow to format the image with $21.

    @Raster: is there a special reason that the "goto Send_ERR_and_Delay" is commented out and replaced with "goto Send_CMPL_and_Delay"?

    We had an experiences that Percom Write command should be confirmed OK always and Error should appears not until following format command.

    (Are we wrong?)

     

    @Raster: is it possible to speed up the blanking process a little bit? I haven't looked at the particular source code, but 30 seconds for 1MB seems a bit long to me.

    There is used one identical method for blanking as for writing ('faccess_offset').

    Clear_atari_sector_buffer_256();

    faccess_offset(FILE_ACCESS_WRITE,maz,(u16)psize);

    IMHO the only way could be bypass the blanking in full, but I don't like such idea at all.

  9. Understand your concerns, but XEGS must be in the minority of users at a guess.

    But They also have right to use SDrive. :)

     

    If you do update/alter the sdrive.atr is it possible to make use of the fire button instead/as well as the return key?

    Fire + joy directions are used for another 4 functions. esc, return, < (home), > (end).

    If the fire button did return directly, there wouldn't be a way to do the other functions.

  10. I guess this has a lot to do with personal preferences and the usual work-flow one is used to.

    Of course. :)

    I'm not sure if I explain my main reason truly.

    It's the situation when I (some user) have created some new unique data (music in TMC, picture in graphics editor, etc.) and then I (he) _need_ to write it for sure.

    There will be too many obstacles:

    * SDcard LOCK - you can't eject the SDcard and unlock the card (loss of all SDrive drives' settings), that's why SDrive has unlock manual switch.

    * SDrive write switch disabled - you can enable it manually.

    * file readonly attribute is set - you can't eject SDcard and permit write to file (loss of all SDrive drives' settings), so there will not be any solution to write data => You have to loss your new created data, sorry. :(

     

    I think you are certain of all read-only file attributes states on all your mediums and all files always. But I'm sorry, I'm not. :)

    So, It's my resulting reason for clear and any time manually changeable switch - read-only (always) / read-write (always).

  11. And if we add an option (ignore/obey read only flags) to the control program? It should be possible to squeeze this into the sdrive firmware and then the user can choose which behaviour he/she prefers.

    Unfortunately it doesn't solve the problem with manual switching for write enable. Again you have to decide in advance, if you want to write or not to read-only images without possibility to change your choice when you really need it.

    And it would increase size of control program and configuration again. I don't like this way...

     

    The reason I added this feature was because I liked to have some finer grained R/W control and to be able to protect images from accidentally changing/trashing/... them. What do you think?

    I fully understand the advantages of read-only protection, but I think that this feature could cause a lot of troubles for SDrive users (and for me of course ;) ).

    Now I have the SDrive in read-only mode default (for protection of all data/programs/etc...) and I'm enabling write-enable switch only when I need it. ;)

  12. Here's an updated version of the SDrive firmware: http://www.horus.com/~hias/tmp/sdrive-hias-090609.zip

    I changed the SIO code a little bit, the new version should work fine with QMEG 3 OS again (thanks to Raster for reporting the bug).

    Thanks. I will test it.

    And I added another feature: the SDrive now honors the "read only" file attribute of (image-) files and won't allow formatting or writing to protected images from the Atari. This means you can have both write protected (important) and writable (for example data) drives at the same time.

    Hmm, I'm sorry but I think it isn't useful feature.

    The reason is in SDrive control philosophy. You haven't any possibility for change "file read only attribute" by SDrive control program not even during your program is running. So, you can use some game/program/tool and if you need to save some unique created state/config/image/music/data, you discover that it can't be stored anyhow. It is the point why SDrive firmware ignore read-only file attribute and it respects manual R/W switch only.

  13. I agree with Mimo.

    Radek, could you make an sdrive.atr (control program) version without OPTION key selection?

    And while you are at it, issue that Poke that kills the loading beep from the computer. Maybe make it configurable for those that like it?

    Although I dislike idea with a lot of different versions (with/without something) as well as increased size of control program due to extensive configuration, I will thinking about it. :ponder:

    But for example control program can't drop the loading beep for booting programs, because it's managed by firmware bootloader. And, by the way, such sounds can be helpful often, you know the loading is in progress really.

    I will ponder...

  14. I am curious about the SDRIVE.ATR file that came with my SDrive NUXX. The ATR appears to be some flavor of DOS 2 that I am not familiar with - command-line driven DOS with a 2.0 style disk format. Yet it identifies the 'Root' dir sorta like SparDOS 'MAIN' when you type DIR and has a file on it called DOSII64.COM. What is it?

    Hello.

    It is DOS II+/D ver.6.4 from Stephan Dorndorf, we like this DOS. Of course, you needn't to use it. You can prepare own SDRIVE.ATR with your favorite DOS, control program SDRIVE.COM (and/or SDRIVEN.COM and/or SDRIVENH.COM) and/or other programs/tools at pleasure.

  15. I don't like the fact that when you press OPTION before pressing RESET or Inverse Video key the cursor scrolls and you hear key clicks sounds.

    Perhaps to keep compatibility with XEGS without keyboard.

    Yes, I'm not glad of this OPTION clicks sounds too, but there is no other way if OPTION has to be used for controlling (XEGS).

    OPTION key is tested at the beginning of OS ROM routine, so, it has to be pressed _immediately_ after RESET, but practically it means to hold down the OPTION before RESET. ;-)

    (SDrive control program can't affect this behavior.)

    btw - I tested GALAXIAN yesterday and yes, it works with BASIC disabled only.

  16. If you need to disable BASIC (with standard OS ROM), you have to hold down the OPTION key at first and then press the RESET key. If you press RESET before OPTION is holded down, BASIC will not be disabled.

    Also in SDrive Control Program you have to hold down the OPTION at first and then press the RESET or InverseVideo key.

  17. Can anyone tell me if it's possible to create blank .atr files on the SD card from the Atari with the SDrive in the same way as is possible on my SIO2USB?

    No, it's not possible.

    SDrive firmware doesn't make any changes in FAT16 filesystem, it only reads FAT and contents of files or write to existing files.

    Though firmware supports operations for read/write SD sectors, so there is theoretical way for any changes on SD card by some special SDrive Atari software, it would be quite complicated and dangerous. It's better to do it by PC.

  18. Hello Raster,

    thanks for the NTSC support...

    so in theory I could simply take the original PAL song and save it without additional editing as 60hz version? if so...this would lead directly to the Metagallactic Llamas NTSC port... ;)

    Unfortunately I think method used in exported XEX is not suitable for ingame music, because VCOUNT register has to be watched hard in program main loop. It's possible to see it when 50Hz song is played on NTSC - playing isn't synchronized with screen, so CPU meter flicker wildly over the screen. ;)

  19. Raster, could You add synchronisation support (as it is in TMC 2?)

    it is not mentioned on feature page, so if it is possible, then i'm sorry for not reading that f manual :)

    In RMT asm player routine there is a lot of variables, some of them can be simply used for synchro.

    For example "v_abeat". It contains track's column which is played, so you can trace its value.

    Also you can check the "p_song" WORD pointer for some specific value (it is incremented by 4 or 8 for each songline from its initial value).

    Greetings, raster/c.p.u.

  20. New version 1.28 of Raster Music Tracker was published.

    RMT website

     

    Changes in RMT 1.28

    -------------------

     

    - Recognition of any changes (indicated by '*' mark after filename in title bar)

    and dialog with "Save current changes?" question (when new song, load song,

    import song and/or when tracker goes to exit).

    - Hotkey for "Cursor go to the track speed column" changed to Control+Z.

    (There is also new menu item "Track - Cursor go to the speed column".)

    - Control+S is new hotkey for "File - Save" from now.

    (If this hotkey is used, messagebox with query "Save song to file '...'?"

    appears and you have to confirm your request. Also you can disable this

    query messagebox in Config dialog (menu View - Configuration)).

    - New hotkey Control+L for "File - Load...".

    - New hotkey ScrollLock for autofollow mode turn on/off.

    - Sound click when "Undo" hotkey is pressed but undo is not possible.

    - Handling of track events with zero volume during manual step replaying

    (by Shift+/Control+/Enter hotkey) corrected.

    - Vertical line separator added between left and right tracks.

    - View menu items settings are stored to rmt.ini configuration file.

    - New functions in menu Instrument - submenu Paste special:

    * Volume envelopes and Envelope parameters only

    * Insert Volume envelopes and Envelope parameters to cursor position

    (Note: Cursor has to be in some column of volume or parameters envelope.)

    * Volume R to L envelope only

    * Volume L to R envelope only

    - New function in menu "Song - Song change maximal length of tracks".

    It also compute effective maximal length value for current song.

    Warning: All tracks can be prolonged or truncated!

    (Note: Computing and setting of effective maximal length is also added

    to function "Song - All size optimizations".)

    - Routine in exported XEX Atari executable msx file improved.

    Now it works well on PAL/NTSC computers and playing speed

    is adjusted automatically to 50Hz on PAL and also on NTSC systems.

    (If configuration is set to NTSC system speed, then 60Hz.

    Note: RMT and SAP files doesn't contain any NTSC type, so playing speed 60Hz

    is supported only in exported XEX Atari executable msx files.)

    - NumLock handling improved (I hope ;-)).

    - Other small corrections and bugfixes.

     

    RMT routine changes

    - New variable RMTSFXVOLUME for sfx volume settings (volume * 16).

    Example "/asm_src/sfx/sfx.a65" has been modified.

    (suggested by Tebe)

    (Coders, you have to use new rmtplayr.a65)

     

    Accessories

    - Atari RMT player RMTPL107.XEX (new version 1.07) is in "player" directory.

    New features:

    * Support for manual entering Device:Filename by TAB hotkey.

    (requested by Baktra)

    * Support for up to 35 subsongs by hotkeys 1-9 and A-Z.

    * Support for PAL/NTSC computer systems. Playing speed is adjusted

    to 50Hz on PAL and also on NTSC systems.

    (There is short description in RMTPL107.TXT file.)

     

    New songs

    - Song "wyjasnijmy_to_sobie.rmt" (by LiSU)

    in "songs/lisu/" directory.

    - Song "bomb_jack.rmt" (by Miker)

    in "songs/miker/" directory.

    - Song "amelie.rmt" (by Nooly)

    Song "summer.rmt" (by Nooly)

    in "songs/nooly/" directory.

    - Song "vietnamska_mise.rmt" (by PG)

    Song "summerdays.rmt" (by PG)

    Song "deflektor.rmt" (by PG)

    Song "xmasmix.rmt" (by PG)

    Song "gpc.rmt" (by PG)

    Song "kaviar.rmt" (by PG)

    in "songs/pg/" directory.

    - Song "mab.rmt" (by Raster/c.p.u.)

    Song "indianajones4.rmt" (by Raster/c.p.u.)

    Song "3d.rmt" (by Raster/c.p.u.)

    in "songs/raster/" directory.

    - Song "sunset_on_the_moon.rmt" (by XLent)

    Song "4tk35.rmt" (by Caruso)

    Song "ilusia.rmt" (by StRing)

    Song "naue.rmt" (by StRing)

    in "songs/" directory.

    • Like 1
  21. Let me make sure I understand something correctly. Although the SDRIVE has four drives that can be emulated, there is no way to swap images between drives on the fly, correct? You can clearly swap 'what is D1' with the three other drives using the front panel, but not actually say swap the image in D2: for the image in D3: on the fly.

    Hello.

    Yes, there is possible to swap D1: with [bOOTimageSDRIVE.ATR] or [D1:] or [D2:] or [D3:] or [D4:].

    But if you switch the SDrive id number to 2 (or 3 or 4), then D2: (or D3: or D4:) is main drive number for swaping with other drives.

    (Of course, if main drive number is different than D1:, then booting of SDRIVE.ATR doesn't work, because Atari is booting from D1: by default.)

    Greetings, raster/c.p.u.

  22. 2GB SD cards (except SDHC ones) are not-standard. Not sure if that is your problem, probably not, but I would test cards with smaller capacity (1 GB or less) just in case.

    Note: Currently I have a lot of SD cards at home - I bought them for testing SDrive. :) Most of them are 2GB and all works well (Elite Pro High Speed SD 2GB (China), EMTEC SD 2GB (China), Kingston SD 2GB(Taiwan), Kingston SD 2GB (Japan)). Also my last purchased 2GB Noname microSD + SDadapter works fine, so I think there won't be a problem with 2GB capacity.

  23. ... You can try writing a block of sectors (maybe 256) and then pausing for a couple of seconds before you write the next block. This should give the SD controller enough time to actually write the data to flash. If that writes to end of volume, try reducing the delay. If you cannot write 256 sector blocks, try a smaller block size.

    Hi.

    I was copying some real 5.25" diskettes from real diskdrive to images mounted in SDrive by Q-meg4. It did fast (69kbps) sequential writing of 1024 sectors (from extended Atari RAM to SDrive) and it was working well, therefore I think there is not problem with missing delays.

     

    I don't believe a pause between activity should be necessary with flash media...

    Me too.

  24. Hi.

     

    a84now@athlon:~/sdrive_temp$ dosfsck -t -r /dev/sda1
      dosfsck 2.11, 12 Mar 2005, FAT32, LFN
      /sdrive_a_l.atr Cluster 451 (1593) is unreadable. Skipping it.

    FAT32 ?!?! WTF(AT32)? ;-)

    SDrive supports FAT16 only!

     

    However, intensive writing, at any speed (19.2Kbit/sec to 89Kbits/sec), fails every time and nearly 100% of the time the failure results in a corrupted file system on the SD card.

    It's strange. SDrive doesn't write anything to any section of file system on the SD card never. It writes only to data sectors with contents of files (atr,xfd).

     

    This happens with two separate SD cards but they are identical (SanDisk 2GB).

    As you can see in documentation, we tested some SanDisk cards and they were working well:

    SanDisk 512MB SD, SanDisk 1GB SD, (China), SanDisk Ultra II (SD/USB) 1GB (China)

     

    Is this problem indicative of these SD cards being incompatible with SDrive?

    I think problem will be elsewhere, but I don't know where.

     

    Should I try another SD card?

    IMHO you should to check your SDrive hardware (main voltage 5V, stabilized voltage 3.3V, voltage divider system by resistors R1,R2,R3,RN2).

    Also it would be good to test this SD card on another SDrive device which works well without any troubles.

    Greetings, raster/c.p.u.

×
×
  • Create New...