Search the Community
Showing results for tags 'Noob'.
Found 3 results
Having recently got back into my old haunt of computers from the 80s and early 90s, I've accumulated quite a pile of them, including 2 ZX81s, a 48k Spectrum, an Amiga A1200, Atari 800XL in stunning condition, an STfm that was damaged in transit but still works (case was bust on one corner), and now an STe. This is again in really good condition, but needs a Retr0bright job on the keyboard, which I'm going to test with the one from the spare ST. As to the electronicals, it looks to be in good shape as far as components go, but I think I have the first TOS, and the dodge DMA chip with the -01 coding. Here's an over-view of the board in pictures: Nothing too weird there apart from the apparent scribble around the mouse ports, but if you can see anything bad, let me know as I want to put this in good order for use with a CosmosEX and such. The only visible problem is with the PSU, which is evidencing a slightly bulging cap on the board, as you can possibly see below. The rest look ok, but would it be sensible to replace them all while I have the soldering iron out? Here's a shot of the TOS chips and the DMA chip. Am I right about the latter, and where can I get myself a new one if I'm to fix it for use with the CosmosEX? I've got a 4160STe badge ready to put on the case, but I want to make sure I'm not already rockin' the 4mb RAM before I lash out on the extra SIMMs. If anyone can tell me off the top of their head if that's the 256kb or 1024kb SIMM, I'd be grateful, but I'm off to Google up the chip numbers myself for good measure as soon as I've finished here Finally a close-up of the "crayon", which either suggests someone's kids have been scribbling on the mobo in the past, or it's some kind of internal checklist at the factory? Me dunno. I'm a bit stuffed for content for Ste at the moment though, as although the FDD works, I have no PCs with built-in floppy controllers to write any disks for memory check routines etc., and my USB FDD is useless with the two DSDD disk writing/reading utilities I've found so far. After I've sorted the DMA issue, I'll be using the CosmosEX to house my pre-existing RasPi, which will have finally found a use!
Serial lurker here... I've been collecting 2600 for some time now. But I'm at the point where buying games is stale... nothing but $50+ games I need on ebay. So Im very interested in starting to collect 7800. I've never owned one but I understand the serials staring with A1 OR A2 are the ones to get. Anything else I should be looking out for? I'm frugal, but the rarer and cheaper I can get the better. dropping hundreds ATM isn't an option. Besides specific serials or models would anything else that would indicate early production runs etc? Oh, and games... I need a good top 10 to start with. Cheaper the better. But games usually come as the deals do. I'm really excited to start this collection process. But I need a clean system first. Thanks so much in advance!
Hi, three things first: 1) I've never used SDX and not even loaded a program for it 2) I know the file format though and wrote a parser for it 3) I know 1) and 2) are a somehow a contradiction, but who said this forum is for logical questions only I have a program here as source that was done for SDX. The author (mono) uses the CPP pre-processor because the code uses symbols relative to COMTAB. The latter I assume is the base address for all system routines, like the EXEC ($0004) pointer under Amiga OS. ; In asm source you must include: ; #include "sdxdef.icl" ; and assembly with: ; $ cpp -P source.asm -o source.a && mads source.a DECOUT2 = COMTAB-21 The reason behind using the pre-processor seems to be that MADS cannot result definition like the one above if COMTAB is a relocated symbol. And when I replace DIVA = COMTAB+255 DIVB = COMTAB+$103 FACA = COMTAB+255 FACB = COMTAB+$103 RESI = COMTAB+$107 by FACA SMB 'FACA' FACB SMB 'FACB' RESI SMB 'RESI' it all compiles fine with MADS without the pre-processor but will must likely not load because RESI for example will not be resolved. What's the reason behind this? Does the SDX loader only resolve a subset of the entries known in this "COMTAB"? If yes, why? I'd assume all entries in COMTAB are "public" (at least the code above anyway codes against that assumption/offsets).