SmileyDude

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.

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!

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.

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).

I’ve typicslly handled things like this by declaring one array and then multiplying by a fixed offset to get to image I want: const unsigned char Images[] = { // Timmy 0b00111100, 0b01011010, 0b00100100, 0b00011000, 0b01111110, 0b10111101, 0b10111101, 0b00111100, 0b00100100, 0b00100100, // RedBox 0b11111111, 0b10000011, 0b10111101, 0b10111101, 0b10000011, 0b10110111, 0b10111011, 0b10111101, 0b11111111, // more images here }; You could also declare it as a two dimensional array if you wanted to hide the multiply.

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

If you do this, it would be cool to include the 2600 version as well, via emulation. As long as you don't include the ability to load other 2600 carts, emulators are allowed on the App Store.

To add a little to Nathan's response, it's also fairly sophisticated inside compared to those $20 styli you can get everywhere. It has an 32-bit ARM SoC, Bluetooth and battery inside. Presumably they are doing some additional tracking of position in the pencil (it knows the angle you are holding it at, for example) and that's part of the reason they are getting the performance so high compared to the cheaper variety. Does that make it worth $100? For some people, definitely -- it's been a while since I priced out a Cintiq, but the iPad Pro + Pencil is very competitive in that space. And it doesn't need to be tethered to a PC/Mac to use it (again, haven't looked in a while -- there might be something all in one in the Cintiq line these days, I just haven't been shopping for one). I knew a few artists that might've actually killed for something like this.

As far as apps go, I'm pretty sure both Acorn and Pixelmator were updated with deep color support recently. Not sure if they posted any example images, but you should be able to see it if you create a gradient in either of those apps. The deep color version will be noticeably smoother on your display.

So is the reported resolution 1080p @ 2x then? How is the performance on those? I know the Mac Pro has a fairly beefy GPU as far as Macs go, but I still worry about performance, especially in apps (i.e, games) that push 3D performance.

This has been my biggest trepidation with 4K displays. Diablo 3 has enough trouble on my 2014 15" rMBP on a non-HD Thunderbolt Display. I can't imagine how it would behave with roughly 4x the pixels. Hopefully this will be a solved issue by the time I'm ready to upgrade in a few years. On the other hand, those displays looks pretty sweet

I gave up on using Fink because I always ran into problems with it. I liked Homebrew because of how it keeps everything contained under /usr/local. Very easy to setup and use. And no real opinion on MacPorts -- never looked into it too much once Homebrew came along

I was looking into this a few months ago as well. I'm also using pretty much the exact same setup as you (quad 2.6GHz i7 Mac mini, external LG drive), so this should work for you as well. https://emulationonmac.wordpress.com/2015/07/26/preserving-cd-and-dvd-based-console-games-pt-3-the-bin-cue-format/ The post isn't Mac specific, but you can install cdrdao using homebrew on your Mac. I think once you do that, the instructions pretty much just work. You'll get both a .bin file (which you can rename to .cdr) and a .cue file in two easy command line steps. I have a few more PS1 discs to rip on my end, so I'll try ripping those in the next few days to make sure I didn't forget anything else.

Looking forward to hearing more -- thanks!

Did you run into issues with getting an ARM cross compiler up and running under OS X? Or was there another issue that forced you into using a VM? Is there any public documentation on the internals of the Harmony cart? I've been thinking of taking a look at doing some ARM coding on the Harmony, but I always end up wanting to know details like how memory is setup, what ARM variant is being used, how does communication happen between the 2600 and the ARM, etc, etc.

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!

Nice setup -- feeling just a little jealous, even though I've sworn myself off the desktop Macs for now in favor of the 15" MBP. The allure of having 6 cores and 2 GPUs in a sleek little package is making me reconsider (though not seriously at this point) my decision The stock config isn't too shabby -- 16GB, 256GB SSD. But ouch, that price But enjoy it -- that is a serious step up from a 2008 MacBook Pro and any Mac mini that Apple may or may not come out with anytime soon.

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

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.

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.