ivop

What error do you get? Could you bring it back to just a few lines that replicate the error and post it here? Or post the full file. Perhaps there is an easy fix.

Nice work! Good to see it continued. Did you also release the source code somehere? edit: actually, my very first player used pre-rendered sid values, generated with sidplay under linux. I never came round to writing some sort of rle based compression scheme as I moved on to include the actual c64 player after that. But, that was when the player was still using two scanlines. Perhaps now it's time to go back there again.

Merry Crimbo to you, too!

This is the classic microkernel vs. monolithic kernel debate (google for Tanenbaum and Torvalds debate 1992 and 2006). Usually, on older hardware, the microkernel (i.e. message passing between processes and threads) is unfavorable because of the overhead of copying messages and data between address spaces. But our 6502 has no memory protection at all, so you could probably get away without this overhead. Your Linux example is flawed though, as the Linux kernel is pre-emptable itself, which means kernel threads can be pre-empted. No blocking process could lock the whole system, even if it blocks forever during a system call. This does add extra overhead though, as more datastructures need locks and mutexes. Consider your JSR into the system. If that's a request for I/O and it blocks ad infinitum, that could be the end of it.

PAL Blending doesn't work on YouTube and a TFT screen either, but if you don't sit too close, your eyes blend OT: looks impressive. As candle says, it's a bit big, but I guess if you are really focused on the game and "into" it, you won't really notice.

No, it's a native application. It involves capturing all USB transactions and reverse-engineering what it all means Work-in-progress can be found here: https://sourceforge.net/projects/g540tool/ Currently, it can read, erase and write an st-m24c16w serial eeprom and read 27128 and 27256 eproms.

http://en.wikipedia.org/wiki/Chinglish But it's quite easy to follow. Read, erase, program, et cetera...

The Willem programmer needs a parallel port, it's only powered by USB (5V 500mA). I recently got the Genius G540 programmer from here: eBay Auction -- Item Number: 221091725115 It includes a bunch of adapters and a PLCC IC extractor. The docs are in Chinglish, but the application is easy to use and I have not had any problems with it. Had to get WinXP installed in VirtualBox though I am currently reverse engineering the driver so I can use the device from Linux.

Sure I would. The problem is I cannot find it I did find the ADC0804 chip, but the schematic was nowhere near it. I checked a few other places, but no luck yet. But I'm sure I'll stumble upon it sometime Edit: I suddenly remembered I've already drawn it in Eagle and threw the paper away. It seems my memory was faulty and it is not exactly the same. But, I remember this sampler working pretty well. schematic.zip

Looks like one of those adc0804 carts I used to have. But it had bad solder joints, so I disassembled it about a year ago, after getting the schematic down on paper. I might rebuild it one day. Nice home-brew double-sided PCB by the way. It's always a PITA to get the top and bottom aligned correctly. BTW Alphasys is here on AtariAge. Perhaps you could send her a message.

Thanks for your reaction! Here's an updated version already. I have simplified some regexps and added string constants. As for .ifdef folding, I do not really like to hide code out of view, but I imagine there are other people that might be interested in your script. Regards, Ivo m65.vim.20121119-1902.zip

See subject. Put m65.vim in $HOME/.vim/syntax (create the directory if necessary) and add the following to your .vimrc file augroup filetype au! BufRead,BufNewFile *.m65 set filetype=m65 augroup END m65.vim.zip

I guess it all depends a lot on the kind of TV you used to use in the past. Our B/W TV cut off a lot more than our colour TV later in life. Both were unable to display the left side of the screen though. My current colour TV has the same problem. If I set the left margin to zero, the cursor in text mode is not visible. That's the reason why I have been experimenting with an ATTiny chip to delay the SYNC signal by a little less than one scanline to have the display more centered. But most of the time I have my 800XL hooked up to a 'bttv' capture card, which has no problems displaying everything that's in the video signal, including annoying blinking pixels way out left or right of the usual display (Bruce Lee has that for example). So, I added a (software) crop filter to get rid of that

Oh well, here is DUP.SYS converted to assemble with atasm 1.07 dup.zip

I am tempted to jump into this discussion, but I won't. IMHO it's best to leave religion and politics out of this forum. General Chat might be an option, but I suppose there are better places on the internet to have such discussions.

I don't think we need a new cart for that. I looked into it and it's just a small patch to make 'B' do the same as 'M' 2080. You can just put his DUP.SYS on your working disk and write MEM.SAV. After that, if you go to DOS from the cart's Turbo Basic, that particular DUP will be read. You can also use an unmodified DUP and do M 2080 to return to Turbo Basic.

I'll have a look at it if I have some time this coming weekend. Could you tell me what this enhancement is exactly? Regards,

Yes, a larger cart is no problem. It just flashes the first 16 banks and then quits. I only have 512kB here, too. For saving files, you need an empty DOS 2.5 floppy. If you do not want to reset your computer to start the DUP, you can put DUP.SYS on it and if you want to be able to link multiple programs without resetting the computer (which means power-cycling if you do not have a reset button on your cart) you can put RUNTIME2.EXE on it as well. Personally, I prefer resetting and running DUP from cart. It's also faster.

Here's a complete Turbo Basic development cart. It includes the following: DOS 2.5 Turbo Basic XL 1.5 Turbo Basic XL Compiler 1.1 Turbo Basic XL Runtime Turbo Basic XL Linker The linker includes RUNTIME2.EXE, but only for a in single link "session". Also, do not forget to press ESC after linking, otherwise the file doesn't get closed. If you just want to flash your SIC! cart with this, you need ...-atr.zip If you want to use the binaries for, say, a MaxFlash cart, you need ...-binaries.zip If you want to see how it's done or change/fix things, you need ...-sources.zip Regards, Ivo turbo_basic_sic_cart-atr.zip turbo_basic_sic_cart-binaries.zip turbo_basic_sic_cart-source.zip

Turbo Basic Compiler BTW I noticed that data/sicmenu.obx that is distributed with sicmenu 0.61a does not work correctly. It crashes loading the compiler. If I assemble my own (mads sicmenu.asm) and use that one to build the cart image, everything works fine. (sicmenu 0.60a source code) Right now I have a cart with DOS 2.5, TB and its compiler. Isn't that what you want/mean Marius? Edit: I also notice that the 0.60a sicmenu loader is waaay faster than the 0.61a that I used to use before. turboc.xex turboc-source.zip

No. Turbo Basic is an application that runs partly from main RAM and large parts of the RAM under the OS ROM. There's no way it'll fit in 8kB, not even with compression. Code generally does not compress very well. BTW The above does not turn a SIC cart into an instant Turbo Basic. It's just an exe file that can be loaded from a sicmenu, or any other $700-based loader for that matter. It's pretty fast though and IMHO it's cleaner than Nir Dary's (sp?) conversion. On-topic again: Any interest in a conversion of the Turbo Basic compiler, too?

DOS 2.5 sicdos25.xex sicdos25.zip