Jump to content

damosan

New Members
  • Content Count

    76
  • Joined

  • Last visited

Everything posted by damosan

  1. Morning All, I'm working on something in CA65 (assembler that comes with cc65) - I need a native debugger that I can run on the Atari that stays out of the way until a BRK instruction is encountered. Normally I'd use an emulator but I'm interfacing with a bit of hardware so I need something on the Atari. Any suggestions?
  2. That would be fun to work on actually. A top/down Ultima style display but with 1000 people stomping through the world. Having it be server based also makes the client a lot easier in that you don't have to worry about coding a story into the client - the server manages the story. It would also be kind of cool to have a bank of 8bits acting as a clustered server to drive it though a Python script on a Linux or Windows machine would probably do just as well. Mmmmm...that'd be slick. As an aside I was working on a Post-Apocalypse Ultima clone two years ago - I got the basics done but stopped working on it. I had planned to target the 130XE so I could store gobs of data and code additional gameplay stuff - as well as a very generic API to support loadable content moving forward (which would be easy to do with CC65 and banking/overlay support). Anyway...back to the Fuji...
  3. Yeah - the work I'm doing is for everything else OTHER than SDX (hopefully). I've done some reading on how SDX does things you can expect relocatable code and loading into high memory instead of the dynamic MEMLO hack that is going on right now.
  4. Relocator update... It's successfully checking for a device on boot. The ultimate goal with this is to have a covers-all-non-sparta-dos environments but we'll see once I get more of the driver in there and test with other DOS environments. Right now the driver is taking 631 bytes of RAM but 500 bytes of that are set asides for input/output buffers (if needed - can be reduced/removed). I plan to implement the rest of the CIO funcs this weekend. At present I show the new MEMLO once relocation is complete, the number of instruction fixes performed, and finally the number of bytes reclaimed after the assembly INIT function is called. I'm running DOS 2.5.
  5. That's the magic right there.... I'll be updating the code to take it back to double buffering and repost.
  6. For common services the URIs/URLs are all basically the same (HTTP, FTP, HTTPS, etc.). We can do the same for TCP and UDP. Instead of "N:TCP:3000" we can do "N:TCP:localhost:3000" which is what people typically do anyway. As far as traditional TCP/UDP comms what doesn't fit into that standard 4-part string?
  7. strtok() is not your friend. It's a man, living in a van down by the river, promising candy to everyone who walks by. sscanf() is also not your friend but it's more like that uncle you only see at Christmas e.g. try sscanf( path, "N%c:%s:%s:%s", bucket, protocol, path, port ) For this stage though it'll be fine - the final product will want a real tokenizer for this. Also I'd suggest that all protocols follow the same format? N:HTTP://sss:p N:TCP://sss:p N:UDP://sss:p It's strange but make parsing easier (and safer) and it's ok if we deviate a bit (for the TCP/UDP).
  8. I'm generally of the opinion that one should try to build their tools first...before downloading binaries. Public binaries tend to lag behind the development tree quite a bit. No. The code already uses pre-shifted bitmaps. The basic rule of "don't compute when you can pre-compute" applies here. Tweaking the PM setup stuff is easy but doesn't really gain much at the end of the day. The part that needs work is that main game loop. Converting it back to double buffering with two display lists would take about 15 minutes (basically call _graphics( 7 + 16 ) twice storing relevant pointers). I'd be interested in a true double buffering GR.7 config using EOR to update the bitmaps on each screen. That'd be useful and remove the flickering - probably getting at least 30fps if not more with no flickering. Trying to figure that part out hurt my head so the flickering version got posted.
  9. I'm going to try to build an asm version of the CIO routines this Sat/Sun using the relocator. I sent a pull request yesterday that makes the relocator a bit smarter in handling data. This week I'm going to add support for an init function that will be overwritten after it runs to conserve memory. The intent is to pop into Basic with everything required to send/rec on the N: device using as little RAM as possible. When i get my grubby hands on a device things will roll a bit quicker - or someone can build the code and try it out and watch it all implode.
  10. I started with the double buffering but the eor'ing sequence made my nose bleed. I kept thinking I'd have to store the position of where the ship was two screens ago so I could EOR the old ship away, update the new coords, and then plot the new position. Is there a code example that does this well? I can study it and then update the code so it runs better. D.
  11. If you get cc65 from github and build it yourself they've added the 0b00000000 thing. It makes for cleaner code IMHO but to each their own. I went back and forth in the main loop - if you remove the pauses you'll get solid objects but as the objects move down the screen they start to exhibit weird visuals. It has something to do with the timing of the physical screen update and the Atari itself. Dunno. If you look at the build string you'll notice that I use "--static-locals" - this has the effect of making locally declared variables "globals" - or more efficiently accessed. Using "--static-locals" is better than making *everything* global IMHO - it helps to keep your namespace uncluttered. Try to make it better and flicker free - I'd be interested in seeing your results. hit_detect() is a mess. The drawing routines can probably be sped up some. I have some assembly code that'd speed things right up but I wanted to keep everything straight C. I've toyed with drawing and updating the player sprite in a vblank. Good practice or no...if it works it works. D.
  12. Interesting - is that a bug in all 6502s? Is it documented anywhere? What I'll do is scan for indirect JMPs first - if I find any that would match this condition I'll shift the copied code one byte and try again. Thanks.
  13. Relocatable code on the 8bit. A question... I'm working on a code relocator. It's pretty straight forward in that it does the following: Moves code from a particular memory region to MEMLO. Remaps a function pointer table at MEMLO for three "public" functions. The relocator scans for documented 3-byte instructions modifying the target to point to the new memory region - BUT ONLY if the target was in the initial high memory range. Updates MEMLO to the first byte past the copied code. It appears to be working. When I do a FRE(0) with DOS loaded I show 32,274 bytes. After the autorun.sys executes I show 32,224 bytes with FRE(0) - the three public assembly routines are very small obviously. The C code starts at address 0x4000 (arbitrary) linking in an assembler file that exports beginning/end of code symbols so the C code knows how many bytes are to be copied. The Question: When looking through the (documented) 6502 instruction list it didn't seem like I'd have to do anything to deal with the zeropage instructions as well as the various single byte instructions. Am I missing something here? I probably should add some of the undocumented 3 byte instructions as well...
  14. I wouldn't worry about that too much - if the examples in the text work as advertised then post away.
  15. Arrays with certain content and under a certain size. The problem is centered around grinding 16bit quantities (the addresses) on an 8bit computer. I've recently started playing with assembly on the Atari, and as a long time C programmer, I wrote C style assembly code i.e. "take this 16bit pointer, increment by two, get the next word, ...repeat..." AAAAAAND my code was dog slow. With the help of some folks here I changed that pattern to using the X or Y register as an index into a memory region of data I was interested in. Well...things started speeding right up. Then if you align your arrays to start on page boundaries life becomes a bit easier/faster. Another key is to Lookup More and Calculate Less. Programming these old machines is fun. D.
  16. It was in an earlier cut when I used it as a flag to do certain things during a vertical blank e.g. in this pass I'm going to update the enemies and in the next pass through the vertical blank handler I'll update the player positions. It worked well enough. I removed all of that when I converted it to use exclusive ors.
  17. Quick question - is it possible to get a 1.0 NodeMCU and run it over USB via an SIO2PC (assuming you install the proper drivers)? My soldering capabilities are limited. D.
  18. I've only ever run it with the Tinkerboard and performance has been a non-issue for me. I'd think you could get a cut running on a PI Zero - it doesn't take much to drive bits over USB cable. I've thought about creating a small touchscreen device purpose built for this but I don't mind running a small linux machine next to the 8bit.
  19. I use RespeQT on a Tinkerboard for all my 8bit mass storage - you can emulate single density drives all the way up to these massive pseudo hard disk size drives with Spartdos. It's a pretty amazing piece of software. You will need to order one of the SIO2PC adapters from Lotharek (https://lotharek.pl/productdetail.php?id=157). There are a few other manufacturers of these devices as well but I prefer the above. Once you get the adapter you plug the other side into a cheap single board computer running Linux or your Windows machine. You load up RespeQT and tell it what USB port you're using and you're off to the races. That said I also have two 1050s and two 810s...but I haven't had to use them in several years.
  20. That's what I love about this platform - there's about 100 ways to do almost anything.
  21. Using the ANTIC (etc.) structure or creating defines results in the same generated code - it's preference really. The linker file is my preferred way to chop up memory in advance (for fonts, etc.) but what is the define you're talking about wrt specifying memory locations for data? Or are you just defining an arbitrary location in memory for your stuff? As far as memmove() it's being used to move players in the pm memory area so there is source/dest overlap once the program is running.
×
×
  • Create New...