ivop

Hi, Does anybody know where I can find schematics of the 410, XC11 and/or XC12 taperecorder(s)? Thanks!

Here's the 6502 assembler I mentioned recently on the Atari 8-bit forum. The reasons to write this were: 1.) None of the assemblers I tried could generate correct code for code assembled to run in zero page and have forward references to other code in zero page, changing their operand in real-time. 2.) I wanted to write an assembler in sh (years ago, I came across osimplay, which I thought was pretty neat). shasm65 is written in sh, the Unix Bourne Shell, with a few extensions used which are not available in all sh incarnations. So far, I have adapted it to work with bash, zsh (~28% faster than bash) and mksh (ksh93, ~52% faster than bash). ash, dash, ksh (ksh88) and pdksh all fail to work, either because they lack array support or do not allow function names to start with a dot. Both issues could be "fixed", but that would make it slower and/or pollute the internal namespace, so I decided against it. Its syntax is different from all other 6502 assemblers, because an input file is treated as just another shell script, which is sourced by the assembler. Mnemonics are function calls and its arguments are the operands. Labels are defined by using the special function L and assembler directives are functions starting with a dot, like .org, .byte, .word, et cetera. Labels are referenced as shell variable names (ex. jmp $label). Numbers/memory locations can be specified in decimal, hexadecimal (ex. 0xfffe) or octal (ex. 0377). To fix the main reason for writing this assembler (see point 1. above), shasm65 uses different mnemonics for some addressing modes. For example, loading A from a zero-page location is lda.z. This way, the assembler knows immediately exactly how much storage an instruction requires. addressing modes: implied no suffix, ex. cli accu .a, ex. rol.a zp .z, ex. lda.z 0xfe zp,x .z, ex. adc.z 128,x zp,y .z, ex. stx.z 64,y (ind,x) .i [,x], ex. lda.i [23,x] (ind),y .i [],y, ex. cmp.i [017],y immediate ., ex. lda. 17 absolute no suffix, ex. dec 0x6ff absolute,x no suffix, ex. inc 0x0678,x absolute,y no suffix, ex. ldx $fubar,y (abs) .i, jmp.i [0xfffe] relative no suffix, ex. beq $loop directives: .org start [dest] start address of next block (optionally loaded at different location) .byte x y z ... include literal bytes (no comma but spaces between the arguments) .word x y z ... include literal 16-bit little-endian words .ascii "ascii string" include literal string .screen "string" include literal string of Antic screen codes .space size reserve size space .align b align to b-bytes boundary .binary filename include _raw_ binary file filename . include source file (shell script, library functions, etc.) L name define label Because both the assembler and the source files it assembles are just shell scripts, you have all of the shell functionality (including calling external applications) as your "macro" language. You can create your own functions, use for loops, tests, if/then/else/fi conditional assembly, arithmetic, all you can think of. # lines starting with a hash are comments # the code below demonstrates a few of the features START_ADDRESS=0x3000 clear_pages() { # start number_of_pages ldx. 0 txa L loop for foo in `seq $1 0x0100 $(($1+($2-1)*256))` ; do sta $foo,x done inx bne $loop } .org $START_ADDRESS L clear_some_mem # inline unrolled loop to clear 0x4000-0xbfff clear_pages 0x4000 $((0xc0-0x40)) rts L host_info .ascii $(uname -a) There are two built-in functions: lsb() least-significant byte, ex. lda. `lsb $dlist` msb() most-significant byte, ex. lda. `msb $handler` Variable-, function- and label names should not start with an underscore or a dot. Both are reserved for the assembler itself. Also, all shell reserved words are prohibited. shasm65 has the following command line options: -oFILE write output (Atari 8=bit $FF$FF binary format) to FILE -v verbose output -h -help --help -? output credits, license and command line options with a short description and their defaults So, why a shell script? Well, because I can, it is fun, the code is short (~300 lines), it runs on many, many platforms, it provides a very powerful scripting/macro language and it's fun So, no drawbacks? Yes, there are. Shell scripts are interpreted and therefore shasm65 is a lot slower than the usual assemblers written in C and compiled to native machine code. I have probably missed describing some features or quirks, but basically, this is it. Have fun Any questions, post below. shasm65-0.91.tar.gz

Yeah, and the one that had the joystick first got to play first The first game I bought was Boulder Dash on tape, after having saved my weekly allowance for months. Turned out to be a good choice. I still think it's the best game of the eighties (Mario 64 being the one of the nineties). Rocks 'n Diamonds is nice and all, but the original Boulder Dash where the scores after each level accumulate is the best.

I think all his 8-bit laptops look great. Totally 80's style. It's a pity though that none of them seem to have an internal battery, or am I missing something?

Back in the eighties and nineties I used Atmas II and right before I quit being active, I switched to Bibo-assembler. Currently I use an assembler I wrote myself, after several failed attempts to get the popular cross-assemblers to assemble a piece of self-modifying code, running in page zero having multiple forward references to locations also in page zero BTW It's called shasm65 and was slightly inspired by osimplay, as it is completely written in bash (yes, the shell) and is about 300 lines of code. Command line. It runs on every platform that has a port of bash (and with little modifications it could be made to run under the Korn shell or zsh if there is no bash). It has all the power of bash as its scripting language. Well, basically, it has all of Unix as its scripting language. You can call sed, awk, perl, matlab, tcc, whatever, inline. It is very easy to extend. It's not the fastest thing in the world. It has a peculiar syntax (but not as bad as it would have had, had I written it in Python ) To me it is For that, I use subversion or git.

That's a pity. It would be great to have three extra timers for something I have in mind. Perhaps future upgrades could have a hardware switch for old (not connected) and new (connected) mode operation.

Something I have been wondering lately (but were too lazy to check the schematics yet ) is whether a dual-pokey upgrade also doubles the timers? i.e. is the /IRQ line connected?

Looked at my 1027 today (which I got in a bulk package once; never used it myself) and the head almost fell apart by just looking at it Anyway, I tried freezing it as mentioned earlier. I froze the whole 1027 and it helped a little bit, i.e. maybe just enough to make a mold out of it. Meanwhile, it has warmed up again and is all gooey and fell apart, but perhaps somebody could freeze a "fresh" replacement and make a urethane rubber mold out of it. It's not that expensive. Maybe $20-$30.

Like Rybags said, your output is signed linear. You can tell sox to convert it to unsigned linear. Also, I suggest you band filter and normalize the input before you downsample, i.e. cut all frequencies between 100Hz and ~1.8kHz and then maximize the amplitude to 0dB. Depending on the sound you are working with, you might also want to run it through a compressor/limiter and normalize again afterwards. This will make soft sounds louder and loud sounds softer, i.e. it decreases the dynamic range but gets you "more sound per bit". Lastly, during your requantization step in Turbo Basic, you could add some white noise to evenly spread the requantization errors. This is called dithering. Shaped dithering is probably overkill and not really useful going down to only four bits, but if you have some spare time, it might be useful to explore too.

I had something similar. About 12 years ago, Intertoys was dumping all their 2600 and XL/XE carts for around 1 euro a piece. They had a ton of them, but I figured I could always buy them later. I never got around to it and now I severely regret not buying them all when they were cheap

Recently I acquired an old Bondi Blue iMac G3 with a PowerPC @266Mhz and 64MB RAM. I upgraded the RAM to 128MB and installed Debian GNU/Linux on it. Runs like a charm. I intend to use it remotely to test big-endian compilations, so I wanted the built-in monitor to be turned off. After searching the net extensively, I was unable to find a solution. setterm -blank 1 does not work (no APM support on a G3), xdpms doesn't work either (no DPMS) and pmset is only available under Mac OS X. I did find a solution though. If you configure Xorg wrongly and select a resolution the monitor can't cope with, it turns itself off. I'd rather not have X installed, but well, a dark server closet is worth the extra few megabytes of disk space And if I need the console because I locked myself out remotely or something, CTRL-ALT-F1 brings back the framebuffer console and turns on the monitor again.

If you like experimenting, you could make your own silicone mold (e.g. with mold max) and after that pour crystal clear urethane plastic in the mold (or any other color, you can even mix your own pigment). It's not that expensive (~20 euro per kilogram each) and certainly a lot cheaper than having it done professionally. A bit cheaper might be C-1508. You have to paint it afterwards though. This method is also nice for cartridge enclosures, et cetera. You could use a relatively cheap paint-on molding material and reuse the mold several times.

I came accross this just now. Here somebody else retouched the Atari 8-Bit font to 8x16: http://www.stevechamberlin.com/cpu/2009/01...fun-with-fonts/

Perhaps you could contact him directly? Maybe they can put all their very old stuff on their website

True but it worked like a charm when I needed to convert samples for a GBA project... Plus you can band-filter and normalize the input first and quadratic rescale and dither the output. Sounds better than just linear resampling and chopping of the least significant bits. That really matters if you go to something like 4kHz/4-bits. Increasing the volume of the source material and running through a compressor/limiter also helps sometimes to get a little bit more bang for a bit.

I actually did trash most of my IBM XT machine (the 4.77MHz one) about ten years ago, including the floppy drive. I only kept the motherboard, the memory expansion and the floppy controler. Recently I thought about desoldering all the 74LS logic so I had some spares for experimentation purposes/breadboarding, until I saw a memory expansion card going for $149,=. Think I'll keep it for a while I have desoldered the floppy controller though for decapping experiments

It's probably an IBM PC compatible floppy disk containing (or used to contain before a C64 user overwrote it?) a demonstration of the Entelekon Power Windows Library or the Entelekon C Function Library (which were MSDOS libraries BTW).

I Just checked my cart. It says: ©1984 Action Computer Services & OSS, Inc. ©1988 ICD, Inc. The cart is black with a yellow label. I seems to be version 3.6.

IMHO all these 65c02/65c816 upgrades with a bunch of 74ls logic are obsolete. Better take something like the Free-6502 Core, add two PIA's, some /halt line code and mimic the mmu (all not too hard) and put everything in a single FPGA. You can also fit in the Basic and OS ROM at the same time. Replace the old RAM by fast SRAM, and only switch to 1.79MHz if ANTIC is accessing it or if the CPU accesses ANTIC, GTIA or POKEY. The second PIA ports can be used to switch to 100% 1.79MHz mode and some extended bankswitching if you want to add more RAM. All stuff can be readily bought and does not rely on decade(s) old and hard to get 65* chips. Also, it sticks to the current MOS 6502 instruction set and the existing bankswitching API, so the code will be mostly backwards compatible as long is it does not rely on the higher speed you can get with an FPGA. Yeah, I know, these are just words... Perhaps I'll get myself an FPGA devel board in a few months

Nice version! I noticed an annoying high pitched tone during the main music though. Perhaps an emulation issue? Rick James's Super Freak sounded right though after I completed four full lines at once. Nice touch

Interesting. I spoke to him a few months ago and he told me he has one of the five complete 1090's (with a cover that is) that exist in the world. I did not get the impression though that he wanted to part from his Atari collection, much less his 1090XL. Well, perhaps it is just showing off, but in that case I would have expected a couple of decent, self-made images. There's something fishy about this ad.

candle, this night I finally found the time to test my second revision design and it turned out the simpler design (compared to my 1st revision) wasn't such a good idea. I lost quite some contrast which I didn't expect cause that didn't show up in simulation, so I will revert mostly to my first design. Well, simulation isn't everything. I did manage to reduce the chroma/luma timing mismatch though, so that part stays. On to revision three When I'm finished, I'll write about it on my blog.

I just tried changing $d208 to $01 (15kHz clock) and it starts to sound better. I think the shooting sound is ok then. The high pitched sound is still there though. I guess that channel needs to be lowered a lot.

IMHO you can just use: lda $900a eor #255 sta $d200 If the octave doesn't match, insert the following between the eor and sta: lsr ; repeat for each octave up or asl ; repeat for each octave down so, two octaves down is: lda $900a eor #255 asl asl sta $d200 etc...

(frequency in Hertz are just numbers I picked, the exact frequency depends on the octave on the VIC-20) A 183 ~220 Hz (0) A 219 ~440 Hz (+36) (440Hz A is an international standard) A 237 ~880 Hz (+18 = 36/2) C 135 ~128 Hz (0) C 195 ~256 Hz (+60) (256Hz C depends on tuning of the 'instrument') C 225 ~512 Hz (+30 = 60/2) C 240 ~1024Hz (+15 = 30/2) So, it looks like the numbers relate nicely to frequencies, and are reverse from what we are used to on the Atari. That's easily solved by taking the two's complement of the numbers. After that, a lower numbers means a higher frequency, just like Pokey. For Pokey, the formula is: F_clock is either 64kHz or 15kHz v = F_clock / F_note / 2 - 1 The 64kHz clock is actually the CPU clock divided by 28. 15kHz is CPU clock divided by 114. e.g. on a PAL machine (braces for clarity): v = (1773447 / 28) / 440 / 2 - 1 = 70.97431 = ~71 NTSC: v = (1789772.5 / 28) / 440 / 2 - 1 = 71.636871 = ~72 I don't have the time right now to lookup a well-tempered tuning frequency table and correlate both chips to it, but it should be pretty easy to do [edit] OK, I couldn't resist VIC Atari 183 --> xor 255 --> 72 219 --> xor 255 --> 36 237 --> xor 255 --> 18 Basically, it's just 'xor 255' to convert from the VIC to the Atari. If it's not the right octave, shift left or right as needed.