Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

190 Excellent

About E474

  • Rank

Recent Profile Visitors

2,464 profile views
  1. Hi, you can also use a raspberry pi and a 5V/3.3 volt logic level shifter, this will work even with a first generation raspberry pi, which you can pick up pretty cheaply second hand, though I am not sure about how common these are in Ecuador, or if they can be shipped for a reasonable price. You can power the raspberry pi with a phone charger (micro USB on the pi), you just need a memory card for the pi, I think 8GB is the minimum (sd or micro sd, depending on which model pi you have). You can also use the pi as a media centre if you install Kodi, and hook it up to a TV with a HDMI cable. You can install the "Atari800" emulator on a raspberry pi, and that supports USB gamepads (but check for compatibility) and USB keyboards. I followed the instructions here: https://blog.lmorchard.com/2018/03/01/sio2pi/ Actually I think I remember @Mr Robot had some problems with ATX files and RespeQt on a pi zero (and I never run RespeQt, so can't comment), so you might want to ask on AtariAge about which models other members use, and then try and get (a second hand) one. If you are only going to use ATR files, you should be ok with a model 1 upwards, and Hiasoft's utilities. Hope this helps!
  2. OK, Maybe save the park for sometime in the future? Just remember "the donkey in the well"!
  3. Hi, I did a quick Google on Park Therapy, and there's a lot of hits that have nothing to do with what I meant. What I meant is explained here https://www.nature.com/articles/s41598-019-44097-3 - basically spending 2 or more hours in a municipal park (or similar) per week is good for you in lots of ways, it doesn't matter if that's 12 * 10 minute visits, or 1 * 2 hour visit, it's just the cumulative time per week. Time in your own garden (if you have one), isn't supposed to be the same, as you can end up looking at work you have to do sometime, which won't be the case in a park. I actually tried this out a year or so ago (I count myself as a scientist, so thought it would be an interesting experiment), and think there is something in it, and as it is free and unlikely to do any harm, I would recommend giving it a try. Sorry if I am spamming the list with this, it's way off any 8-bit topic, but I thought it was worth clarifying what I meant.
  4. Hi, Sorry to hear that, that's an awful lot to deal with. I've found doctors to be a bit variable, so I hope you luck out and find a good one for treating your cellulitis (it's something I know very little about). Have you considered making a schedule for yourself for some "(municipal) park therapy" (and giving it time to see if it has an effect)? Also, maybe getting a book on CBT (Cognitive Behavioral Therapy)? It sounds like you are a bit overwhelmed, and that's when it's most difficult to figure out what you can fix for yourself. Kudos too for sharing! Good luck with your recovery, hope it's not too long in the making.
  5. Hi @ijor Thanks very much for extending the ATX spec, I'm guessing it should cover almost all situations, but is there any way to handle data stored between sectors, as used by Disk-Master 1050, described here: I appreciate that having some sort of "Gap-Data" record would probably bloat the file as it would almost always be noise, but I can't see a simple way of recording this info, so perhaps include it as an extension to the ATX format, but assume it is optional during the imaging process, e.g. very rarely used, so not a default choice. Unfortunately I have my hands full at the moment, so can't be of much help, but if the ATX format is going to be revised, it would be nice if some mechanism for capturing this info could be included, just for the sake of completeness. Thanks again, and hope this helps!
  6. Hi, I had a similar problem, and @MacRorie very kindly uploaded a couple of files for blanking the EPROM/firmware. It's in this thread - on the second page - am posting just before calling it a night, so apologies if I have skimmed over the problem, etc. Hope this helps, and if it does, maybe worth updating the docs?
  7. Hi, I guess I am seconding a lot of previous posts, but I would go for the beep when holding down Start on bootup (and possibly sound of tape blocks loading), drive head movement noise when a 1050 is powered up (not sure about 810), disk drive bad sector grinding noise when a sector is re-read, and sound of regular SIO disk transfer, but also high speed xfer sound on a US Doubler, or similar (beep-beep-beep brrrrrrrrrrrrrh). Also the very funky bassline on BallBlazer, quite a lot of the sounds from Bandits (and Star Raiders and Centipede), the sound of a humanoid being picked up by an alien in Dropzone, music and sound effects from Shamus, Preppie theme, and keyboard speaker effects on Bug Attack! Some of the sound effects from Missile Command are iconic, Encounter also has some great sound effects, the Kleptangle approaching in Wayout. The sounds of enemy knights materializing at the start of a Joust level (and some of the other Joust sound effects). Not forgetting the digitized voices in Ghostbusters, or the surprise in Rescue on Fractalus.
  8. Hi, I think the Archiver/Editor manual has some information on disk protection. There is some info on programming a Happy drive in the first 5 issues of Atari Magazin 1987 (in German), I think the example code includes examples showing how to use the Floppy Disk Controller directly, there is also the data sheet for the FDC, which I think is a WD2793 which I think has some info on how data is organised on a track. Also, you might want to look at the ATX specs, as that will give you an idea of what a flux image can be converted to. Are you planning on writing code that will actually run on an 8-bit Atari? Hope this helps!
  9. Hi, Thanks very much for the technical explanation - I think I understand it. Presumably the Happy would store the current value of these 4 bits in a variable somewhere, and then use them when it was transferring data to the 8-bit, so it should be in the code starting at $F000 (see https://github.com/e474/DUMP1050/wiki/Atari-Magazin-Happy-Programming-Course-Article-1) in the Happy ROM. I had thought the simplest way to handle high speed transfers would be to read from the track buffer (assuming it could co-exist with the 2K LUT and uploaded code), and use the Happy subroutines to read sectors and tracks into the Happy RAM. I think that is still a valid approach, provided I can dig out where the bit pattern is stored.
  10. Hi, I have the 51 page 1050 Field Service Manual - the schematic with the RIOT on it is on page 47. I'm not much of a hardware hacker, but it looks like RIOT pins 24 - 21 and 19 - 16 are mapped to PORTB, with the RIOT wired up as: pin Port B bit Connected to 24 PB 0 -> Data Out 23 PB 1 <- VCC READY 22 PB 2 -> NS04 21 PB 3 -> NS03 19 PB 4 -> NS02 18 PB 5 -> NS01 17 PB 6 <- Data In 16 PB 7 <- CMD I'm assuming that writing bits 1,6 and 7 don't matter (they are input values), but how exactly should bits 2,3,4 and 5 be set? I can't see how you can specify a track number (0 - 39, or 1 - 40) with only 4 bits, so how should you set these bits?
  11. Hi @brenski, Have you tried my DUMP1050 utility on the drive, to see what ROM images get returned (assuming it works)?
  12. Hi, Nice! That is much better code (IMHO) than mine! I don't understand the comment about rebuilding the tables for each track, unless some of the bits in PORTB_DATA are used for specifying the current track? Out of curiosity, which bit in PORTB_DATA is used for SIO (actually, does anyone have a description of which bits mean what, and maybe also for PORTA_DATA)? Presumably you could rebuld the tables with: LDY #0 LDX #NEXT_TRACK_BITS + SET_BIT LOOP LDA #NEXT_TRACK_BITS + CLEAR_BIT STA (ZTABLE),Y TXA INY STA (ZTABLE),Y INY BNE LOOP And modify the operand for the LDX and LDA per track, and ZTABLE for the bit table 0-7? I don't have access to my 8-bit kit at the moment, which is very annoying!
  13. Hi, thanks for the feedback! It sounds like the code on the 1050 needs to be a little slower. I think adding NOPs between outputting each bit would bloat the code too much, so maybe it is better to JSR to either OUTPUT_BIT_SET or OUTPUT_BIT_CLEAR in the TRANSFER_DATA code? Providing these routines are on the same page, you are only updating one byte in the TRANSFER_DATA routine per bit output. Not sure how many cycles per bit, but code would look something like: TRANSFER_DATA JSR OUTPUT_BIT_SET JSR OUTPUT_BIT_SET JSR OUTPUT_BIT_CLEAR .. OUTPUT_BIT_SET STA PORTB_DATA RTS OUTPUT_BIT_CLEAR STY PORTB_DATA RTS But it would be a constant rate. You might as well unroll the code for testing each bit in a byte of sector data, the basic idea is: 8-bits -> 8 bytes, each byte is the low part of the address of either OUTPUT_BIT_CLEAR, or OUTPUT_BIT_SET then the 8 bytes get copied into a block of JSR statements for outputting that particular data byte. LDA DEST_JSR_TABLE STA (Z_DATA_TRANSFER_BLOCK),Y INY INY INY LDA DEST_JSR_TABLE+1 STA (Z_DATA_TRANSFER_BLOCK),Y INY INY INY ... LDA DEST_JSR_TABLE+7 STA (Z_DATA_TRANSFER_BLOCK),Y CLC LDA Z_DATA_TRANSFER_BLOCK ADC #30 STA Z_DATA_TRANSFER_BLOCK BCC ONLY_LO INC Z_DATA_TRANSFER_BLOCK + 1 ONLY_LO although I don't know if it is really worth unrolling this code as putting it inside a loop would not slow it down that much. Only other code would be data byte -> 8 bytes of lo jsr addresses.
  14. Hi, I was thinking about what would be the best way to generate the transfer code, and thought maybe: CREATE_SKELETON_TRANSFER_CODE ; LOOP TO FILL TRANSFER_CODE WITH SKELETON CODE BYTES LOOP1 ; FIRST BIT OF BYTE .BYTE ??,#<PORTB_DATA,#>PORTB_DATA ; SECOND BIT OF BYTE .BYTE ??,#<PORTB_DATA,#>PORTB_DATA .... ; EIGHTH BIT OF BYTE .BYTE ??,#<PORTB_DATA,#>PORTB_DATA .BYTE #OPCODE_FOR_JSR,#<WRITE_STOP_START_BITS,#>WRITE_STOP_START_BITS ; BRANCH TO LOOP1 IF THERE ARE MORE BYTES IN THE BUFFER TO GENERATE SKELETON CODE FOR RTS You only need to call this routine once, ever, as the ?? will get replaced when you process the actual buffer data, and the rest never changes. ; A CONTAINS VALUE FOR STOP BIT ; Y CONTAINS VALUE FOR START BIT WRITE_STOP_START_BITS STA PORTB_DATA STY PORTB_DATA RTS For processing the bit value in each byte, probably quicker to use an 8 byte buffer to store each STA or STY opcode, depending on the value of each bit of the byte being processed, and then update the appropriate set of 8 instructions in the TRANSFER_DATA unrolled code. I think the code from @HiasofT would be the best basis for extending to support this transfer speed, so it could be possible to actually have read from drive speeds at this speed. If you were looking at a specific use case like copying an unprotected disk from Happy Drive 1 to Happy Drive 2, you might as well delegate formatting the destination drive at the start of the copy, and read the track layout of the source (that is, transfer a list saying which sectors in the current track have data), then only read and write those sectors. Also, if you wanted to transfer 256 byte sectors, and had to do UPDATE_SKELETON_CODE, execute code, UPDATE_SKELETON_CODE, execute code, you would know fairly accurately how long to wait between 128 byte transfers as the UPDATE_SKELETON_CODE should take the same amount of time to execute, regardless of the actual byte data (I think).
  15. Hi, I think you could unroll the code for writing individual bits from a byte to the transfer code, but you would have to loop through the sector data byte by byte, and jump over the code for stop and start bits. You could also replace the send stop/send start bits with a jsr to a routine to do this as this would result in smaller unrolled code. You could just about fit unrolled code for 256 byte sectors into the Happy memory (probably not for a 6K Happy), but you would have to give up the track buffer, though you could probably try and buffer the next few sectors. If you were dealing with 128 byte sectors, then you could handle those in 3k of unrolled code. If you wanted to handle 256 byte sectors, you could generate unrolled code for 128 bytes of data, execute it to transfer that data, generate the code for the next 128 bytes, then execute that code to transfer te data. Unfortunately that would mean a pause halfway through a 256 byte sector as the code for the second half of the sector's data was generated. I don't know how well this would be tolerated, but on the other hand, if there is custom code on the 8-bit for handling the transfer, I think it would be OK. Actually, for a single density disk, you would have 18*128 bytes = 2304 bytes for the track buffer, 3K for the unrolled transfer routine, so you could probably get the maximum throughput on a 6K Happy, at which point you would have to consider if your receiving code on the 8-bit could keep up.
  • Create New...