potatohead

No. The clocking of everything is locked to the NTSC / PAL display signals. (sorry)

Just splce it. I made one of these a while back and they work great. I used the yellow cable for the luma, because plugging that one into either a composite input on an ordinary TV, or the port on the 1702 results in a nice monochrome image. Then use some other color for the chroma signal. I used green. If you want, you can buy a cable that does this. Google "s-video to rca cable." Interestingly, you can also take that cable, plug both RCA ends into one of those combiners used to connect stereo audio gear to mono audio gear, results in a mostly usable composite signal. google "rca y cable" This signal can look sharper than the one which comes out of the device, if the device has a composite output. Non-standard, but useful. Edit: Hey Al, why can't we copy / paste images in posts?

Menu draw speed is really notable. I love following this project. You are doing an amazing job.

Nice! Yeah, I would write that disk off and feel really good about getting the data off of it. Next. I too have one of those telephone pick up things! They are simply amazing. Very good call.

I write on mine too. Love the feel of it.

It had some special characters, but no pixel addressable display.

I have the folding one. Last I checked, it still worked. It had the 20 character display... Originally, I bought it to help with some college classes. I would write programs to solve circuits and some physics problems, then run them for tests. Since one could store text, sometimes I would just write notes too. Later on I wrote a set of programs to calculate sheet metal unfold to flat pattern dimensions for a variety of materials. Used the crap out of the thing, until I ported those to a CAD system running on a PC. The pocket computer was a great investment. Most of what I used it for was plain old boring work. Paid off though. One time, I tried doing a fractal on the thing, storing the image in an array where it could be viewed on the little display by scrolling around. It sort of worked, but it took a long time to generate anything and the small display just wasn't good enough. Had it been pixel addressable, I would have done a lot more.

I follow those things, and particularly enjoy the Open Apple Podcast. My Apple has been acting as a terminal for some micro-controller related adventures, plays some Ultima, and I do some programming on it from time to time. Mostly just tinkering, but it's fun.

This is really easy. Just set the date for 5 years from now, earlier if life permits, done, next, and that's kind of what one would expect from a spectacle. If the other party is talking, I'm cool with it. Stuff happens. I wouldn't set a date either, if I didn't have full control over when things get done.

For cassette, I really liked what they did in the Color Computer. A DAC / ADC was used with the CPU to read the cassette data. That system ended up being very robust and fast! The Atari and POKEY did this in blocks. Blocks were kind of nice because there was some time for processing things as data came in, but they weren't too nice just due to how slow that cassette system was. Can this be sped up? Just wondering. Anyway, the CoCo just dumped it all as one big bit stream. Start it, load it, done, stop. Blocks could be done easily, and it's a software only process using the CPU like that. Seems to me a tape could be used very well, and on the CoCo was, including file names and types. I second the I/O priority. In the end, that proves much more useful. But, I must say having at least 80 column capability native made a big impact on how a machine was taken back then. External 80 columns would basically mean it's not used much, and even at that high baud rate, might not work well for many things that onboard video would... Interesting discussion! Seems to me, one could make a similar argument for sound happening via serial too.

That is precisely what I did, along with a CoCo 3 for programming fun. My //e continued to be a workstation for basic things all the way into the 90's. Once it was setup with the right cards, disk, printer, joystick, mouse, it was a capable machine. I did the basic office type stuff on it, and played games and programmed it. Nice machine. I got hold of a PC right at the end of the 80's, and it was a slow beastie. Since I was into CAD and industrial automation kinds of things, which paid the bills when writing and office stuff didn't, having a PC made perfect sense. I could game on my 8 bitters and did! For newer games, consoles were just fine and that is what I did too. Offshoot 16 bit computers like the ST and Amiga were never going anywhere but for a few niches, music, video, etc... and I wanted them. But, I wanted to build a career too, and so the choice was simple. Keep the 8 bitters for fun and run the PC for skills and to make money. That played out very well. "Hobby" activities have paid for every machine I've ever had since. When I buy them, it's for fun and I buy old 8 bit computers for fun. Because of that, I'll pretty much never explore the 16 bit scene. The complexity is just high enough to really take some mind share that I would use to continue building skills to sell. Skills that happen today on a PC type machine running Mac OS, Linux or Windows. SGI IRIX was in there for a while through about 2004. Made seriously good money working with IRIX and people doing high end academic work, industrial CAD, etc... Fun machines, but also dead ends today. When the bottom fell out of those, it was back to the PC and 8 bitters for entertainment. Still have a //e, and it's on my work bench acting as a terminal for some micro-controller related projects, the odd game and programming and I'll probably build a card for it at some point. Anyway, for those people who did go into 16 bit land, I'm envious. But, then again, I'm often envied due to the skills investments I made on a PC, and that started with an Apple ][. And that always seemed to be the path from the beginning. Most 8 bitters were game machines that could do some other stuff. Most 16 bit computers were game machines that could do some other stuff. Most of the work got done on the workhorse machines and that was the Apple ][ and PC. Work pays the bills, and it funds fun. Seemed obvious at the time, so that's how I played it and it all worked out just fine. Today my Mac is the fun machine. I do some work on it, but mostly not. It's entertaining and gorgeous. Some people do CAD work on them, and I've got mine to support that activity and it's a great development machine for micros. The PC? Pays the bills big. Linux? That's what I run when I want to do my own thing, or I've got some tasks that I really don't want to buy licenses for, micro controllers, etc... And to me, that's the meaningful comparison. The Atari 8 bitter is great and was great then. The C64 was a very similar kind of great then and is great now. Both were those home programming, gaming, etc... machines people had. And the only real difference between them is the time period they rocked hard. C64 lasted a bit longer due to it's release date and I firmly believe it's higher color resolution, which allowed for character type graphics. And I mean characters as in Mario characters. My very favorite gaming experiences are the Atari ones, because that was the first with the VCS and the 8 bitters both having that look, sound and feel. But, the world moved beyond abstract gaming. The NES showed up and with it, square, small pixels on the TV. The C64 could do that, the Atari really couldn't in the same way. I think those differences carried the C64 a bit farther, just due to how things evolved.

KABOOM! Every so often, I have to have a long play session.

Scratch that. Seems my Apple is pissy.

If the image works, I'll do it later this evening. I'm home now where the Apple is. No big deal to put it on a USB and run through it.

Yes. Very nicely done. One of my favorite parts of the development to watch.

Totally. It is worth the lark to see what was done. Yeah, having the interrupt there makes a world of difference. A quick CPU doesn't hurt either. What strikes me is the good graphic design. That odd pixel ratio on the Apple is ugly, but it didn't have to be that ugly.

You are right about that.. Funny, I would glance at various parts of the screen and would miss it. Another look shows that when I just focus on the screen rather than details. Guess that comes with your critical eye on this project. In any case, no draw on I/O that I could see. Mostly, no draw for any reason on the Apple, LOL

Somebody else will have to comment on the mouse for sure. Apple generally did not employ interrupts, so my guess is polling. I think it is skipping draws on most activity. Modal. If there is a screen draw that overlaps the mouse, it just gets drawn over, then replaced last. That means typing with a significant font would blow it away too. Of course, the user is modal too. One is either using the mouse to pick or do, or one is typing, or one is waiting. Seems to me the mouse is just last draw on the draw stack, and there is no drawing during I/O. The Apple has its low level RWTS read write track sector in RAM, and it is nearly all CPU, but for a bit of clever discrete logic on the disk controller. This brought the Apple a very fast disk for it's time, as well as higher capacities and various formats, but it came at the cost of doing essentially nothing during I/O. About the best possible would be to cram something in between sectors slowing things down considerably.

There it is. Just a little work from there setting up other apps. Thanks for finding that.

Nice video. Are you running that on a CFFA? And is that Apple stock, or sped up? Came back here to report I don't have a disk setup like that anymore. Never had one that good actually. Would love to get a disk image to show off to a few people.... hint, hint. Yes, it looks to me like a fairly lean draw system. Get it done quick and only draw what is needed. The addressing on the high resolution or double high resolution screens didn't exactly make for high throughput. The signal is there to sync the mouse up, but no standard interrupts, meaning one needs a card, a hack, or poll for it, so they don't. Lots of stuff on the Apple is that way due to the simple computer design in that respect. Your GUI project is excellent. Mouse Desk was one I actually used for a time back in the day. Fetching apps was a bit slower than that video, and I can't really remember the draw speeds. So far, the Atari is posting up nicely. Generally agreed. After looking at the "draw it when possible" method, I think it's cleaner as you envision it.

Yeah, just change the pointer. I totally agree with that. IMHO, the biggest value add there is consistency. Of course, the next question is where to draw the line? Is it a big deal on a few files? Probably. One file? Maybe. Disk access while something is running? Likely. Just musing here late on a Friday... Perhaps there will need to be options. For something that needs the I/O to work in a sane, timely way, indicate that's happening and shut the mouse down. For other things where the mouse might make sense, limit the I/O, and keep the mouse operable. Maybe a final one would be sort of a batch, "get it done as it can get done" option where the mouse gets priority. If the user is moving it around, stall the I/O, slipping it in whenever there is time, leaving it for the user to manage. Keep the drive spun up until it's all done. Users would quickly modify their mouse behavior in a fairly transparent way, but it would exercise the drive more. Maybe that's not a big deal, given flash / SD card type storage options. Could be useful for some application that can tolerate I/O delays. (don't ask me what that is, maybe somebody will write for it, if the option is there, that's all) Perhaps a puzzle game fetching assets might look like this as would a text editor that is operating on a very big file. Dang, I should boot some stuff on the Apple and examine how it's done there. Seems to me, single applications just block the mouse out during I/O. For the desktop stuff, there was text mode and graphics mode. I never did run any graphical desktop on an Apple, but I did the text mode stuff. Correction, I did use the one below. Did not remember until I saw the video. Most use was the text mode desktop, which was fast and used with Appleworks. What I can't recall is the mouse priority on something more complex than a quick blast to disk. Maybe it's always locked out and the users deal with it, or use keyboard more of the time. When I was using real Atari disks, I recall them being about 1/3 to maybe 1/2 the speeds I experienced on the Apple and CoCo computers. Both of those could go quite fast, depending. CoCo had the disk controller, and the Apple just had the CPU. Most of the time, those machines just got the I/O done quick and the user was back to doing whatever. In emulation, I've seen the Atari disks go a lot faster. How fast are they on real devices these days? I don't have an SIO device for the Atari, but I do have a SD cartridge for the CoCo 3, and it's much quicker than a real drive ever was, though I don't know about hard disks. Never ran one back in the day. The same is true for the Apple using that CFFA device. Maybe this isn't so big of a problem when not using real disk drives? Then again, depending on what people do, data might be a lot bigger, but it could be in chunks too...

I got bogged down and briefly revisited this. Had just started figuring out CC65 bank mappings to segments to the virtual disk file. A quick look on 6502.org shows that somebody went ahead and wrote a Merlin compatible assembler! PoP now builds on Apple 2. (all kinds of awesome there) So then, there is now another choice. Rather than get it ported into another assembler, that one can be used to fork an Atari version. Didn't Bill Budge release something he wrote for the 800 and wasn't that in Merlin as well?

That is what the ESC key is for. Seriously. I suppose the optimal workflow would be to prompt the user on the copy or move operation with a dialog that says, "press ESC to abort the operation" and the little OK and cancel buttons there for them to decide on doing it or not. Once started, cancel goes away, nobody cares about the mouse much and the user has a nice out if they need it. On ESC, complete the file operation, or roll it back, whichever is closest, throw up another dialog that reports what did happen, and give them an "OK" to dispense with it after having seen what they need to.

I did this on a Thinkpad T60p and it worked fantastically well! The basic process was to create a boot CD to shim the proper boot environment into place using the OSS Darwin core. Once that was created and working, I could use a CD or USB key to boot Mac OS. A blank hard disk accepted the OS, and support for various things required some creative editing of .kext files. Once that was done, I honestly had no trouble with it and ran it a lot. Now I have a MacBook Pro, so I've no need for the Think'ntosh, but it was great while I used it. Mac OS performed better than XP or Windows 7 did on that machine BTW. My reason was to actually support a Mac CAD application when I didn't have a Mac! Took 'em a while to get that all done, and so the T60p was the ticket. I ended up really enjoying the experience overall. I think what really made the difference on that model was the ability to basically shut down, pull a hard disk, slap another one in and boot right back up. The T60 has a stupid easy drive port that can hold a disk in by friction well enough to use.

Well, it's true there is no VBI, but syncing to the screen was possible on the Apple ][ series by reading the video display contents on the "floating bus", and that could also be augmented by storing some easy to recognize values into the screen display "holes", regions of RAM that get scanned but not displayed. The //e and C have a VBLANK signal which makes things easier. Just compute it, then wait for VBLANK, compute it again, etc... Whether or not games actually did this, or relied on page flipping is another discussion. Many didn't use it, simply because the page flip worked well, or the overall FPS was low enough to make a simple page flip work, particularly on the slow phosphor "business" screens so many users used. Those are typically the monochrome, green, amber and grey phospher displays, not home TV sets, which we all know can and will display a lot of flicker.