SmileyDude

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.

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

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.

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.

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.

Don't need the portability of the MBP anymore? I just went the opposite way from a 2012 mini to a 2014 rMBP and so far, I am very pleased with it. Even with the small bump decrease in specs from the mini (2.5GHz i7 vs 2.6GHz i7), it's still a bit faster for some of the stuff I do. Plus, unlike the mini, it can reasonably drive a 27" Thunderbolt display without being pushed to the edge. Of course, we'll have to see what Apple finally does with the Mini this year (next year?) to see how it does. I have a suspicion that until Broadwell chips start hitting the market, Apple might not update the mini.

This was exactly what I needed. 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!

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.

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!

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.

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

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.

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.

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.

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.

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.

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

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!

I've been following along with these posts for the past few weeks while you have been posting them. I think they have been really good so far, but I think it might be helpful to have everything you need inside the post rather than having to download the source each time. I was able to get up to step four on my own by working off what was in the post, but I had to download the source to see what you had done in regards to positioning the objects. But I also have a little bit of history with hacking on the 2600, so I would guess that others might have to look inside the source code even sooner. Otherwise, I think you've done a fantastic job. Would love to see more after you are done with this one where you do a deeper dive into a topic -- perhaps a more complex game or a different game type. It's nice to have a tutorial where you end up with an actual game at the end vs a tech demo. I think most people start running into problems when they go to make a finished product vs just getting something small up on the screen.

Hello -- When the Visual 6502 team did their talk about their original project, they showed that they had done the same with the TIA as well (http://visual6502.org/docs/6502_in_action_14_web.pdf -- starting at page 39). I know they've released die shots of the TIA, but does anyone know if they released the polys or the net list for it somewhere? It would be incredibly useful to have this information preserved for the TIA, in addition to what they've already released for the 6502 itself. It does seem like the project has grinded to a halt on the public side. Is anyone here involved with the project? dennis

Fantastic -- looks like I'll be placing an order soon! My kids love playing with the Vectrex, I just don't have as many games as I used to (lost over the years, unfortunately).

You need an Xcode before 4.0 to build for PowerPC, I believe.

Looks like the VecMulti is sold out -- doh! Shame because I have the Vectrex now.

I'm thinking it would be more like having an enhanced 2600 game than anything else -- but looking over at how the 7800 works, I'm not exactly sure how it would be enhanced. If you are driving the TIA instead of using the MARIA chip, there really isn't much other than extra RAM that the 7800 has over the 2600. Still, it might make an interesting demo at some point.

Couldn't someone craft a single ROM that would pass as a valid 7800 game to the 7800 BIOS and also be able to run on the 2600? The 6502 code would then have to detect if it was running on a 2600 or 7800 so that it could take different code paths as necessary, but that would allow a cart to have the ability to have an expanded set of capabilities on a 7800 while still being backwards compatible to the 2600.