Jump to content

Daedalus2097

Members
  • Content Count

    125
  • Joined

  • Last visited

Community Reputation

62 Excellent

About Daedalus2097

  • Rank
    Chopper Commander

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Glasgow, Scotland

Recent Profile Visitors

1,345 profile views
  1. This was a retro-styled mobile game written by a friend of mine, and the pixel artwork just happened to suit the Amiga's native graphics so it was a good candidate for an Amiga port. I've just finished the port (rewrite is probably more accurate), and it's now available here: https://nivrig.itch.io/dodgy-rocks and on Aminet: http://aminet.net/package/game/actio/DodgyRocks. It's an endless run and dodge, high scores type of game. It should run on any Amiga with 1MB of chip RAM, though it's tight so a little bit more makes it more comfortable since it needs to be run from the OS.
  2. Heh, maybe I'll put it on the list of projects for if I ever finish everything else I'm working on Yeah, the ECI thing is kinda annoying, but that should be a pretty simple PCB to convert to PBI, right? Or vice versa. For such a bus device, a simple PCB or cable that allows connection to either type would be a no-brainer to include I'd say.
  3. Looking at the 1090 schematics, there isn't anything there for bus arbitration, meaning the $D1FF scheme can easily be implemented by the devices themselves (and their software). There's actually nothing in there but some buffers and a power supply, but there's some good documentation on the addressing scheme which is very interesting and will come in useful. As an aside, it's a pity the pinout of the slots in the 1090 isn't a mirror image of the PBI connector, otherwise reimplementing it with a small gender-changing PCB to plug into the slots would give you the ability to use both PBI and 1090 boards in the same setup. Something similar would still be possible though... Are there enough PBI devices out there that being to connect them all at once is a problem?
  4. Awesome, thanks everyone, lots of great information here. A quick skim through the Altirra manual looks promising, seems to be lots of relevant detail. And that RS232 project looks excellent I shouldn't need to worry about swapping out the FP region, it'll be pretty simple I/O stuff that I'd be doing. The 1090 I hadn't heard of, but atarimuseum.com has schematics and some design notes available that might be helpful too, especially for passthrough-type implementations.
  5. Awesome, I'd really appreciate it if you could dig that up. I was thinking of building an Atari - Amiga "clock port" interface, which could open up access to a wide variety of peripherals easily accessed through an 8-bit bus and a handful of registers. That would include parallel and serial interfaces, I2C and SPI controllers, ethernet modules, hardware MP3 decoders etc. It should be easily enough done with a few latches and gates, or maybe a small CPLD depending on exactly what it ends up looking like.
  6. Yeah, that's where a Wiki or database would come in useful, to see which bits and registers are used by which hardware devices and which are potentially free. But maybe having $D6xx and $D7xx as options with external decoding would do the job. Incidentally, if you were to connect multiple PBI devices to the machine, how would you do that? Is there normally a pass-through connector on HDD interfaces? Or is there an external busboard of sorts?
  7. Ah, sorry, the $D4xx was a typo, it is indeed $D5xx, 6xx or 7xx. Yeah, $D5xx would mean incompatibility with cartridges, I guess it's an option for when $D6xx and D7xx are already in use elsewhere. The $D1xx space is interesting, I'll check it out as it was potentially PBI I/O hardware I was thinking of. Overriding internal addresses is all well and good, but if I override, say, an area of RAM, how do I let BASIC know it's no longer available for use? Sounds like $D1xx is what I'm looking for though, provided nothing else uses it... Thanks very much for that! I wonder is there a suitable place to add a list of peripherals and their addresses for reference, maybe an A8 hardware wiki or similar?
  8. Is there a comprehensive list anywhere of the various peripherals available (old and new) and the memory locations they map to? For example, it would appear that the $D500-$D7FF region is a good place to put experimental hardware as I don't think it can be used for RAM and the decodes for the region (well, $D600-$D7FF) aren't connected on the XL. However, reading the Altirra hardware manual seems to suggest that some RAM expansions bank extra RAM over this region, which would make them incompatible. Lotharek's COVOX product appears to have the option of being mapped to $D5xx, D6xx or D7xx space, which is good to know, but it would be useful to have a decent list of all peripherals so I don't have to try and find that sort of information on them all... Thanks
  9. Yeah, I had an early 486 at the time, and it was definitely impressive for some specific games. I wasn't that interested in Doom, but flight simulators, while they still weren't texture mapped or anything, were significantly smoother than on the Amiga. The sound was dreadful, and I still used the Amiga for most of my games, where 2D and sound were still still superior. A little while later I got a 68060 CPU for my Amiga which brought it up to scratch speed-wise, but at that stage there weren't many new games coming out for the Amiga, and the PC was definitely showing its muscle in the games arena. So I'd say possibly the 486 era too, when sound cards and CD-ROMs started to become more common, though 3D acceleration was where it really took a leap for me.
  10. Yeah, that's a classic error of installing to the boot floppy instead of the hard drive. You need to select where to install Workbench, which means you need to already have a blank partition set up and formatted, ready to go. (Incidentally that's the same for emulation as on real hardware )
  11. It depends on what drivers you have installed. Driver files in Devs: don't do anything unless something actually uses them, but also you shouldn't get any issues with 8MB of fast RAM without actually using the drivers, i.e. you've inserted a card. If you don't insert a card, it shouldn't make any difference. That said, there are millions of hardware-software combinations and I certainly haven't seen them all. If the only device you're set up to use is a PCMCIA CF card adaptor, just dragging the CF0 DOSDriver out of DEVS:DOSDrivers and into Storage should be enough to disable it. Otherwise, show us your startup-sequence and we can see what might be causing the issue, and what lines the seller might be talking about. It's one of these issues that isn't specifically either party's fault, but the seller sounds like a bit of a dick to be honest. 8MB non-PCMCIA-friendly cards are pretty common, and it's a poor show to not foresee their use. I only use my own setups though for this very reason - so I know exactly what's in it and can easily solve issues if they crop up.
  12. I haven't used one on the ST, but I go with the FlashFloppy firmware on Amiga Goteks. Adding a small OLED screen too so that filenames can be seen instead of a number will help too. It's a pretty simple modification (can be done without soldering) and the OLED screens are cheap as chips. Edit: Direct link to the OLED modification: https://github.com/keirf/FlashFloppy/wiki/Hardware-Mods#oled-display
  13. Haha, that was my first thought too! Excellent work though, well done!
  14. I frequently use winUAE under WINE, and it works pretty well. I'm not entirely sure if Linux will allow it to mount a block device in the same way though... Sounds like you have a working method though - the very same process should work for the SD card.
  15. Are you accessing the card as a directory, or as a hard drive? An SD card should not show up as a hard drive that's ready to have files copied to it unless it's already been prepped for Amiga use. If it shows up in Workbench at that point, it's not a real hard drive, it's just the PC drive mounted on the Amiga side. Prepping a drive in FS-UAE isn't something I've done myself, but in WinUAE you need to mount the card as a hard drive device, and you can only do that when you run WinUAE as an administrator. Then you use HDToolbox to create the partitions required and reboot the Amiga. Only then can you format the partitions, and only after formatting can you install the OS on it. Most of my drive prepping though I just do on the actual Amiga for simplicity and so I know it'll work on that setup, but using UAE can be a time saver on the other hand.
×
×
  • Create New...