Dasm strings and macros

[Dasm strings and macros]

That actually was an interesting suggestion.  I think I had heard of that years ago and then forgot about it.  I just spent a little time re-working my print method to do this and it works perfectly.  Thanks!

 

That said, it would still be interesting to hear if there is a way to use segments that way in dasm.  I’m sure I’ll wind up wishing for it again one day.

[Dasm strings and macros]

Hello -

 

Does anyone know if it’s possible in dasm to have a macro reserve space for a string in another segment than the segment the code is being assembled in?  For example, I want to have a macro like this:

 

MACRO PRINT
  lda #<.string
  ldx #>.string
  jsr printString
  jmp .skip
.string:
  .byte {1},$00
.skip:
ENDM

but without needing to do that jump at the end to skip over the string.  Instead, I want to put all the strings together in a single place and let the macro handle the details so I can just say:

 

PRINT "Hello World!"

and it works correctly.

 

The above macro does work, but it ends up wasting 3 bytes for that jump.  Which is why I want to just push all the strings into a separate segment after my code.

 

Thanks!  

[What assemblers are being used these days for 2600 dev?]

Interesting responses.  I’ll probably just stick with dasm for now, since it works.  But I’ve been dabbling with the NES and Apple II a bit and there just isn’t much support at all for either of those two platforms in dasm.  I’ve managed to make things work, but I had to do a lot of defining of registers myself that I didn’t need to do with the 2600.

[What assemblers are being used these days for 2600 dev?]

The last time I looked into 2600 homebrew, dasm seemed to be the assembler of choice.  But on other 6502 platforms, it seems cc65 is more popular these days.  What are people here using? I’ve used dasm quite a bit, but support for other platforms seems limited (the NES, for example).

[Need some help with dasm include enhancement]

I had setup a GitHub repo years ago for dasm. I think it was just a fork of whatever the latest version I could find at the time along with some fixes I needed on the Mac.

 

https://github.com/munsie/dasm

 

I don't know if it's helpful or not, but it is the version of dasm that I use for my own 6502 development. So at least I know it works

[Visual TIA]

Looks like the Visual 6502 folks posted up a new project to run the 2600 SIM (with TIA and 6502/7 in net list form) - http://blog.visual6502.org/2014/10/atari-2600-simulation.html . Looking forward to seeing what happens with this now!

[Reading a peripheral card's ROM and Sider HDD sasi "firmware" version.]

It's really easy to read this, no special tools necessary. Just read from $Cx00 - $CxFF, where x is the slot number the card is installed in. You can even use the monitor to save it directly to tape (example for slot 6 -- replace with whatever slot you are dumping from):

*C600.C6FFW

Or if you have a floppy drive available:

]BSAVE ROM,A$C600,L$100

[Question about 6502 Assembly source code and Merlin (Apple II)]

This has actually been done already. Take a look https://www.tindie.com/products/option8/retroconnector-keyboard-interface-for-apple-iie/

There are also adapters for Joysticks by the same guy.

 

I figured there was something already done in this area, but was more thinking of doing it just to figure out how to do it myself. But this is still pretty cool -- interesting that they used a slot just to hold the card and not for any actual electronic connections. I guess this would be a good use of slot 3 on the IIe, since it's pretty much useless otherwise once you have the 80 column card installed.

[I wonder if it would be too hard to get this on an Apple...]

That game looks pretty cool, actually. It would be an interesting challenge to get that over to the II. I think if you limited yourself to monochrome displays, you could probably get something pretty respectable. Dunno if double hi-res would make it easier/better, but that might be another option. Would limit the game to the IIe/IIc/IIgs, but I think that would be an acceptable tradeoff at this point. Plus you would have access to more memory (128k, bankswitched), if that ends up being a problem.

[Question about 6502 Assembly source code and Merlin (Apple II)]

I think I used a IIgs keyboard on one of my Macs at one point. Not as good as some of the other Mac keyboards, but definitely better than that squishy Mac keyboard was shipping with their Performas in the 90s. Ugh.

 

As for the IIe keyboard, it is pretty close. I find it pretty nice to use, except for it being a few inches higher than the Mac keyboard. Perhaps if I lowered my desk a bit, I could deal with it better. But for now, I'll stick to my cross compiling setup

 

It would be kinda cool to rig up an something (perhaps Arduino or similar based) to allow a USB keyboard to plug into a II. I might take a stab at that sometime just for the heck of it

 

The //e layout is pretty close to that of a modern keyboard, and of course the IIgs keyboards were also Mac keyboards, if that makes things any easier...

[Apple IIc and Atari 1200XL...like ebony and Ivory...]

I always like the how the classic Apple IIs (II, II+, IIe) all could have a set of drives and monitor sitting on top of them all nice and neatly. The IIgs also had a nice default setup as well.

 

I loved my Ataris as a kid. We had the 400, 1200XL and 65XE while growing up, but it always felt a bit awkward to position them relative to the TV (always a TV with them as a kid -- we didn't have the money to buy a dedicated monitor back then).

 

My favorite of all, though, was the Amiga 1000. I *loved* that it had an area to slide the keyboard under for when you weren't using it. I think it would be pretty tough to setup an A1000 and not have it look slick.

[Apple //e to Apple II Monochrome Monitor, which cable do I need?]

I've got a gray Apple cable somewhere, but right now I've got a cable that I pulled out of a broken 2600 in between my monitor and my Apple IIe. I'll probably rectify that at some point, but for now it's working fine.

[Question about 6502 Assembly source code and Merlin (Apple II)]

I've never used Merlin, but I have been using dasm to cross-assemble to the Apple II. I'm already familiar with the syntax of dasm since I've been using it for Atari 2600 development, so it was really easy to keep using it for the Apple II as well. Also I'm too used to modern keyboard layouts that the Apple II keyboard still throws me off a bit. It's not as bad as some machines (ZX-80/TS-1000 comes to mind as being particularly bad), but I'd much rather have some modern conveniences while writing code so I can save some more brain activity to put towards the code itself rather than trying to deal with old text editors.

 

As for deploying it to real hardware, I've been making cassette images for now. I'll probably need to switch to some other method at some point if my Apple II projects get more complicated, but for now this is working pretty good.

[Outputting header bytes with DASM]

-f# controls the output format, 2 might do what you need.

 

This was exactly what I needed.

 

You can define a couple of labels 'start' and 'end' at start and end of your program.

 

Then you would do this:

.byte start,start>>8,(end-start),(end-start)>>8
start:
...your code...
end:

 

I was initially trying something like this, but was running into problems with multiple .orgs. I didn't want dasm to pad my output file. I guess I could've gone with one .org, just 4 bytes ahead of my real origin. But that didn't really feel right. Maybe that's just something I need to get over myself, though

 

For now, SpiceWare's answer works for me.

 

Thanks!

[What is the single worst thing about your classic computer.]

ECS?

 

Anyway, my biggest beef would be, I have an Apple //e, and its floppy disk capacity is a piddly 140K. Yes, I know Atari 800 users have it even worse than that.

 

The 1050XL with a Happy mod got us up to a whopping 180K, but eventually the Apple II line got 3.5" discs with 400K, 800K and eventually even 1.4MB of storage. All of which would work with your //e with the right cards. I would much prefer the //e for storage capacity over my still beloved XL

 

And yeah, I know there have been advancements for the Atari 8-bit machines in recent years -- but Atari (AFAIK) never shipped a drive for the 8-bits anywhere close to what Apple did for the Apple II. So much wasted potential.

[Outputting header bytes with DASM]

This is kinda off topic, since it's not for the Atari 2600, but I figured I would ask it here since I'm using DASM for this. I need to be able to output a small header at the front of a binary generated with DASM -- 2 bytes for the start address and 2 bytes for the length of the assembled file. Does anyone know how I can go about this easily with DASM? I would rather not do this with a separate script of some sort in my Makefile. Since DASM should already know both of these values, it would be ideal to do it inside there.

 

Thanks!

[Apple II tape formats]

Again done. Look at the c2t source. There is an option to compress. The compression is 6502 simulated by c2t to judge if it would be faster to just transfer vs. transferring the decompress code + binary + decompress time. Examples of a compressed binary and an uncompress binary:

 

Oh, this is pretty neat, but I was thinking of compression of the binary tape file itself, not the data within the tape file. But I can see both being useful.

 

I'm going to have to check out c2t some more. I've written some code to generate tape audio before -- nothing too fancy. Lately I've been using the little Apple II emulator to generate tape images, but again limited to what the stock firmware will do. Definitely want to push the limits a bit more on the tape interface.

[Apple II tape formats]

IMO just roll your own format.

 

Have header/descriptors that summarise the bitrate, length etc for each data block then just pack the data as the computer would finally see it per block.

 

Line of thinking here being keeping the data as compact as possible without actual compression taking place, and allowing the original media to be reproduced if required.

Some level of compression would be nice -- even if it's just basic stuff. For example, instead of putting in 5 seconds of the leader, there should just be a indicator that there is 5 seconds of the standard leader. This would allow for complete reproduction of the original media if necessary, while also not filling up the file with useless data.

 

I'm thinking that wrapping the entire file in LZW or similar compression afterwards might be a good second step. Similar to how a lot of emulators zip their ROMs for storage purposes. Not required, but could be nice to have. I'll worry about that later

[Apple II tape formats]

One more thought of why to use a binary format rather than a WAV. A wav file can contain any audio information, not just Apple II tape images (obviously). By using a binary format, there has been some validation on the underlying data before hand and it should mean that images can have a higher success ratio than wav files. I've ran into quite a few tape images off the web that were bad -- mostly because they were captures off the original cassette and they failed for the same reasons the cassettes originally did back in the 80s. I've been able to clean up some of these dumps off line, but some are beyond repair for me at the moment. A binary file completely bypasses at least those failure points and gives some assurance that the data is there.

[Apple II tape formats]

If you're planning an app that will assist loading programs, why not copy the bootstrap idea in ADTPro, so the iPhone at first will transmit a small program that loads on the Apple, and then a list of disk images (yes) present on the phone. The Apple user then gets to traverse into an image and select a file that will be transmitted over audio. I realize it takes a good while to load programs that way, as I've had the joy of transferring those 140K disk images using only audio as my A2 clone lacks a working serial port.

 

I would love to see the details on loading a disk image over a tape -- the Apple II doesn't even have enough RAM to hold a entire disk in memory, right? But at the very least, I can see this being useful as a way to bootstrap up an Apple II system where you have no formatted floppy disks available. Use the tape interface to load in DOS 3.3 or ProDOS, insert a blank disk, format and install the system on it. That would be pretty useful in my opinion.

 

I do like the idea of having the iPhone act as a server of images. Using the tape out port to communicate back to the iPhone would be pretty cool and even allow for multi-load games. I'll have to think about that one some more.

[Apple II tape formats]

so you want to use computer power to convert a binary to audio on the fly to cut the overhead of a 44kb file?

I want to use computer power to convert to optimal audio on the fly so that I can take advantage of either better tape decoding software on the target machine or a faster CPU without having to re-encode for every possibility. The 44kb file was just one byte encoded using the defaults for a regular Apple II cassette. If you try to use higher baud rates, you have to increase the sample rate as well. Of course, you should get a shorter length file at the same time. But looking at the higher baud versions vs the lower baud versions of the files I have, the higher baud ones still end up being a bit larger byte wise, despite being shorter time wise.

 

If you look on the site I linked above, they have at least 5 different WAV files for each game they offer -- basic and monitor load versions in both hifi and lofi, which are different speeds, along with a CD optimized version as well. That collection of games takes up 1.5GB alone -- even if you throw away half of the files as being redundant, you are still looking at 750MB of storage being tied up for what's probably less than 1 MB of actual data. And since I'm thinking of making an iPhone app, where the device size goes down to 8GB (which is really more like 6GB of available storage), it would be a bit silly to use that much space that the user probably wants to have for music, videos, photos and other apps, especially if it's not needed.

 

And really, generating the audio is *not* that computationally hard -- remember, the ~1MHz 6502 in the Apple II was generating and decoding this audio in realtime. I already have code that will take a binary file and generate a WAV file that can be used with a real Apple II.

 

So yeah, a little code, a 50:1 or more savings in space (before applying other forms of compression like LZW even), I think it's a fair trade off. Does it make as much sense on a high end desktop/laptop with 1TB + of storage? Probably not. But there are other devices that are much more limited in storage in use these days, so why not?

 

Plus, we are talking about retro computing here -- this is almost certainly nobody's full time job. We are all here for the fun and the challenge of it and to scratch our own particular itches. If we tried to justify any of this beyond that, we would all be coming up short

 

Edit: One more thought I had -- a 44kb file is almost *all* of the RAM the Apple II had. I know we live in a bounty of computing power, but it still feels a bit wrong to represent a tape image meant to load onto an Apple II with a file that takes up way more space than a room full of Apple IIs had available in RAM.

[Apple II tape formats]

I'm trying to think outside of the box now...

 

If you're planning an app that will assist loading programs, why not copy the bootstrap idea in ADTPro, so the iPhone at first will transmit a small program that loads on the Apple, and then a list of disk images (yes) present on the phone. The Apple user then gets to traverse into an image and select a file that will be transmitted over audio. I realize it takes a good while to load programs that way, as I've had the joy of transferring those 140K disk images using only audio as my A2 clone lacks a working serial port.

 

Assuming the Apple ][ operates tapes at 1200 baud (higher? lower?), it would result in just below 9 kB of data per minute? It means a 700 MB / 80 minute CD-R would hold about 700 kB, i.e. roughly a ratio of 1 MB audio file per kilobyte actual program. So on a 8 GB memory card you should be able to fit 8 MB of Apple ][ games stored as CD quality audio (44.1 kHz 16-bit stereo), which would be way above your actual needs.

 

Another idea instead of compressing with mp3 or zip, would be to downsample the WAV to perhaps 11 kHz mono, 8-bit samples which I would imagine is enough. That is assuming the original WAV files you're handling are of a much higher quality. While the sound quality loses more on doing that, I think the risk of data loss is less from downsampling than lossy compression?

I am already using 11kHz, mono and 8-bit -- and even that is overkill in someways. The Apple II only had 1-bit audio for the cassette port, so the other 7-bits are just wasted space. For normal Apple II tapes (i.e, written with the Apple routines in the monitor code), the highest frequency tone is 2500hz. That would suggest that going down to 5000hz for the WAV file would be enough.

 

I just did a quick test -- even with 11khz/mono/8-bit, a 1-byte save file still takes up 44kb. Obviously for longer files, this gets much better -- adding another byte to my save file only adds about 50 bytes or so to the WAV file. But a 50:1 increase seems quite silly when we could just store it as a binary blob and let the serving app just convert it on the fly to the audio format. This also means that as improvements are made, like higher bitrates, the app can be upgraded without having to upgrade the storage format. You could just set the slider to the higher bitrate and use that.

 

Anyway, I'll be doing some more experiments on my end to see what can be done.

[Apple II tape formats]

WAV's really all that's supported...

 

That's a bummer. Maybe I'll try to come up with a format that would compress down a bit more and lend itself to be loaded directly via the emulator. Using 800k to store a one line basic program when most of the wav file is the 770hz header tone is crazy. Even with today's storage options, that could add up fast. My local copy of the game server archive is a gig and a half, which would be a lot of space being used on my iPhone if I wanted them over there.

 

I hate to think what MP3 or AAC would do to a tape file. Especially the ones at the Apple II game server that have the fast loader on them. I might be overthinking it, but it seems like there would be plenty of opportunities for a compressor tuned for music to garble up a tape file.

[Anyone still type in programs?]

I just typed in a couple of AppleSoft programs tonight, actually. I've been programming in C/C++ and Objective-C for so long that it hurt to type in line numbers. It didn't seem like such a primitive way to write code 25+ years ago, but today it's downright horrible at times

 

Amazing the things we dealt with before more modern machines and the Internet came along

[Apple II tape formats]

Hi Everyone --

 

I've been playing around with the Apple II tape format again (this time with a little Apple II emulator that I wrote), and I was curious if there was any sort of "standard" for distributing tape images in the Apple II world. I've been using .wav format with just the pure audio in it, but it seems to me that for emulation and archival purposes, that a more compact format could be made. Something similar to the .tzx format over on the ZX Spectrum side, for example.

 

Does anyone know of such a format for Apple II emulators? I realize that the .dsk format is the more popular format, but tapes have the advantage of being able to be used with real Apple II/II+/IIe without having a working Disk II, card and floppy disk around. Hence my interest in tapes at the moment. Ultimately, I plan on making an iPhone app that would be able to hold a bunch of these tape images (Apple II at first, but nothing saying that other formats couldn't be added later) and then get hooked to a real machine for loading.

 

I do know about the Apple Game Server, which is fantastic. But their distribution format is limited to wav files and a text dump from the monitor, neither of which is very compact.

 

Thanks!