Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

wierd_w

Members
 View Profile  See their activity

  • Content Count

    1,621

  • Joined

  • Last visited

Posts posted by wierd_w

  1. Posted

    I got mine with power cord, and RF modulator for 40$.  It was a steal.  The RF modulator is snowy as hell, but as I recall from having been a kid in the 80s, they were that way brand new. :P

     

    I have a composite cable ordered though. Should get it in a few days.

    • Like 1

  3. Posted

    The Ti I got off ebay about a week ago works just fine.  It was a little skimpy on the packing materials, but WAS shipped in an original OEM box. (which was packed inside another box.)

     

    About the only issue I have had with it is that the RF modulator is snowy as all get out, but that is kinda expected.

  4. Posted

    I am considering an upgrade to the 2 cassette cable from the single cassette cable I currently have.
    (I picked up ANOTHER cheap walmart ONN cassette recorder. It will be much easier to configure cassettes with the FINDEX program with 2 cassettes, so I can quickly load the indexer.)

    Should I go ahead with that plan, do you want/need a cassette cable?  Without some kind of storage device, the system is kind of a pain to use aside from cartridges. 

  5. Posted · Edited by wierd_w

    3 hours ago, FarmerPotato said:

     

    I've been imagining what Tursi's HAM could do on a tile based screen (not bitmap. Perhaps EC2). If the palette changed for every line, you still don't get "enough greens" on every row, but maybe every other row. Would this be sufficient to create awesome textures for a game tileset? Like granite, metal with specular highlights, green monster parts... the goodies of early 90s VGA games.

     

    If the screen were divided into horizontal zones, that would open up possibilities, but my imagination is going in the direction of a platformer that scrolls in horizontal and vertical.

    There was an interesting vga dither routine that was used in wizardry 7 (msdos). It was used to generate the larger inventory screen portraits, from the smaller in-game thumbnails.  Literally, the large portraits are produced from the smaller ones. (I think they were 16x16 pixels for source image, and nearly 64x64 for final image. ) it was pretry complicated, but it judged what new pixels and patterns to add, based on its neighbors.  I remember this because I spenthink ages looking for the higher resolution portrait data in the games files, but could only find the thumbnails.  

     

    Something similar in concept could be used to tile-ize a smaller bitmap, that obeys the row-by-row color attribute restrictions, and uses less program memory.  At least for backgrounds.  They would be dithered, but it could be neat to look at and unique.

     

    Here's some images to help you understand.

     

    This is the normal play screen.  See the character portrait for bolor.

    274492-965460614_00.gif

     

    Now, look at the inventory screen for that character.

     

    274495-965460630_00.gif

     

    The second image is generated from the first one, by the dithering routine.

     

    We could do something similar, grabbing 4x4 areas in the source, and expounding them into 8x8 areas that obey Ti color conventions. 

     

    This specific ditherer came to mind,  because if you look closely at the large portrait, you will see the local palette is different every other line. The dither routine selects colors that are appropriate, based on the source pixels, but with a different palette.

     

    Designing images for such a routine is challenging, but not impossible. 

    • Like 1

  6. Posted · Edited by wierd_w

    The FINDEX program recent posted in the Cassette Power! thread could arguably be expanded in this capacity, just with lots of user intervention.

     

    It already puts a small index data block at the front of the cassette (it stores 10 records), but uses a fixed indexing schema.   If instead you put the tape load routine at the start of the tape (and you already know how large this routine is, so you can reliably skip it to get to the index right after it from a freshly rewound tape), you can get the indexer into memory reliably, then you can get the index into memory reliably, and from there, you can get to any file on the cassette reliably.

     

    If I wasnt so horribad at programming, I would look into writing a more advanced DSR for the TI that can handle arbitrary files...

     

    DSRs are out of my league, but I can probably improve his indexer to have arbitrary number of indexes, with proper (not fixed) location seeking.  You just need to have a routine that holds cassette motor control line low, and count a desired number of seconds, then raise it high. (then prompt user to press stop.)

     

    The user would have to know how large a program is in memory. (There's an extended basic command that will return memory free, which can tell you the size of the loaded program, but sadly it does not live in stock ti basic.) This would complicate adding an index, but that's fine.  You could get many more programs per tape, and could seek reliably.  His program already seeks pretty damn reliably with its fixed indexes. Just, if you have a REALLY large program, I cannot guarantee it wont go past his fixed index position boundary.

     

     

    (See the cassette power thread.  I gave better instructions on how to set up tapes to use that indexer, because the vintage documentation is rather incoherent, and rambling. It does not explain how to use the program acceptably, IMO.  However, once you set up the tape with the indexer in position 1, you have room for 9 more programs (or adventure modules) on that cassette, and the stock indexer already has a means of putting 3 comments on the tape, allowing you to indicate which, if any, programs at the fixed indexes are adventure scenarios.)

     

     

  7. Posted

    SDCards containg a full fledged microcontroller inside (So do USB flash sticks).  this is how they are able to handle reads and writes at 512kb sector sizes, when the flash media inside them typically has a 2 to 4mb (yes, MB) erase block size.

     

    Those cunning people overseas have ways of reprogramming these microcontrollers. This is how they are able to report the incorrect size.. They could also be used to do all manner of unscrupulous things to a computer they are connected to, so I would be very wary of any "Deals" on flash memory of any kind. 

     

    Sadly, this "512kb sector is actually emulated" behavior of SDCards makes me a sad panda.  It means that improperly formatted rPis will burn up their storage with write amplification (you can get around this by having the Pi format the card CORRECTLY, but most stock images for the pi make no attempt at this!!), and also means that if you use an SD - CF adapter with a nanoPEB, the sdcard will get burned out. (You really need to write in aligned blocks the same size as the erase block, or the micro controller inside the card will read-erase-modify on every single write, overwriting the same flash cell hundreds of times.)

     

    That's a topic for a different thread though.  Just be wary as hell of "shockingly inexpensive" flash media, and of media from China all together.

     

     

    • Like 1
    • Thanks 1

  8. Posted · Edited by wierd_w

    Are these IBM PC clones, or something else entirely?

     

    If the former, you might consider something like a laplink cable, or getting a parallel (or scsi external) zip100 drive. These would not be permanent installations, just used to get data into and out of your legacy, "certified" hardware deployments.  (Use the 'guest.exe' program that came with the external zip drive with a real bootable diskette, then copy data at 100mb a shot.) 

     

    Another possible choice on a modern system, is an LS120 (Superdisk) drive.  While intended to be a contender for iomega's zip disks, it offers full back support for 3.5" IBM formatted diskettes, and lives on an IDE interface. 

    https://www.ebay.com/itm/NEW-Digital-Research-internal-SuperDisk-Drive-LS-120-DRLS120-FACTORY-SEALED/174033397996?hash=item288532e8ec:g:Tj0AAOSwZCFdgIUk:sc:USPSPriority!67570!US!-1
    (supposedly new old stock. There are cheaper offers, but those are refurbs.  You do not need the 120mb media. It can read and write 3.5" diskettes. It does so crazy fast too.)  I have tested iomega's internal zip100 drives on sata-IDE adapters, and those work fine. I suspect the superdisk would too.  Dunno if win10 would know how to deal with it properly though.

     

    edit:
    Some cats at vogons have gotten one working in win10 with some caveats.

    https://www.vogons.org/viewtopic.php?f=46&t=50435

     

    One thing you should check though, with your old-stock scsi units, is for the presence of the switch mechanism in the left-hand side of the door. That is what detects if the disk is high density or not.  If there is no little switch there, then the drive is low density, and will NEVER read a high density diskette.

     

     

  9. Posted

    I have basically abandoned the tech industry.  I'm a skilled SAN person (have experience, and credentials. Know what I am doing), but the US is just not a healthy country to do tech work in.  I have strong memories of providing support to overseas operations, and their administration staff was so much more chill, with so much less pressure and stress involved.  Here in the states? the kinds of issues those cats were dealing with would have had senior management breathing fire and threatening outsourcing every second the problem continued.  Those cats in the UK and AU? "Cheers mate, take your time."

     

    Rather than suffer early heart attacks or strokes, I left the industry. I make like a third of what I did, but I already paid off my house and car loans, and have no student debts. I can afford to live on less, and the reduced stress is totally worth it.

     

    Doesn't change my being a computer nerd deep inside all the same though.    

     

    One thing to consider, where the costs of computer tech then vs now is concerned, is that the devices made then did not have economies of scale behind them driving prices down.  I remember an often quoted statement from an IBM engineer that he felt there was a market for perhaps a dozen home computers in the whole of the United States. These days the idea of not having a computing device in easy reach is unthinkable; Back then?  The idea of having computers that are ubiquitous was what was unthinkable.  See for instance, this early CBS Presents segment from the early 60s.  The commentator doing the interview honestly has difficulty with even the very basic concepts of computing, and how computers work. He legitimately could not imagine how the future would turn out.

     

     

    As a consequence, while computers were very much coming into their own in the 80s and 90s, early demand was low, and so there were not huge orders of products being made. As such, the industrial underpinnings of production did not have the capacities, and the costs of procuring, processing, and shipping both raw materials and finished products were just that much more expensive.  Prices naturally reflected all of those aspects.  The amazing thing is that despite those obscene costs, people who understood what a computer was and could do, still wanted one, and wanted one badly enough to sink that kind of cash.

     

    While I got to miss out on much of the early experiences of these old 8 bit micros, (I was a rugrat at the time. Did not get to enjoy being a computer nerd until the very late 80s, to early 90s. The computer we had at home was an IBM PCjr, which had... numerous failings. ahem.), I did get to experience the last great push before the commercialization of the internet, and computing as a commodity.  I still remember how "Shocking" the revelation was that "We can now build and sell 500$ computers, retail."  We are now down to sub 200$, or even sub 20$ computers. (The raspberry Pi is more machine than I really care to think about, in an absurdly inexpensive package. The computers we put inside appliances just floor me some times.)

     

    Were we crazy?  No, I don't think so.  We saw something others did not.  

     

    • Like 1

  10. Posted

    That's the kind of thing I would first slip into an ESD sleeve, then surround (completely, no dead space inside) with the large-cell air packaging material, in an oversize box. While cartridges should be fine without the ESD sleeve, I simply don't trust these people handling boxes.  My experience with that printer just reinforced my prejudices in that respect.  The large cell air packaging? NOT OPTIONAL. With how light the package is, those nutjobs are sure to be tossing the damn thing around like a football, or stacking stuff on top of it that will crush it. 

     

    The printer I got had shredded newspaper, and insufficient quantities at that.  It should have had something like bagged foam done instead. (which is what I would have elected for, had I decided to go through with an ebay return. I decided that such a headache wasn't worth it, and that I could just fix the printer.)

  11. Posted · Edited by wierd_w

    16 minutes ago, matthew180 said:

    I have thought about that.  So 2-bits of alpha and 6-bits of palette?  Is that acceptable?  Keep in mind the palette would have to be shared with any tile layers and sprites. 

    76 543210
AA|PPPPPP

    Alpha blending would have to come at pixel scan-out time though, which may complicate matters.  I'll have to think about it a little.  Also, alpha-blending might be *cool*, but is it as useful as having a full 256-color bitmap?  I'm not a big fan of effects at the expense of usefulness.

     

    Palette expansion might be a possible option, but working out how to make it usable to the other parts of the VDP other than just the bitmap would take some thinking and effort.

    Used right, it could be very useful.  If you are updating lots of pixels, that is going to slow a lot of things down. Its faster to poke at some registers and get similar results. This kind of thing was done to do palette effects on VGA cards in the DOS days. Fade to Black, Fade-in, etc-- can be used creatively to cover up slowly drawn areas.  It can add a lot of polish.  

     

    One such condition: Simple drop shadow under a sprite.  By making it 25% black, the layer underneath shows through. To do the same effect, you would have to be pushing many more pixels to dynamically update the drop shadow. Having to dynamically update the screen like that just for a sprite to move 1 pixel, is what really put me off from qbasic's graphics routines. Sure, it has a fully addressable 256 color mode with fully definable colors, but no easy way to handle sprites as distinct from the background; You end up blasting so much data in and out of the framebuffer that the whole thing comes to a crawl. TI basic gives you that for free, just with fewer colors and more restrictions in other areas.

     

    As regards the color palette density-- I can do a whole lot with 64 colors, if I get to choose what those colors are. Most of my images only need 8 to 20 colors. The headache comes with pre-defined indexed colors that were picked for their mathematics, not their optical perception.  (THAT is when you end up with situations where "I dont have enough greens!" and pals. When you dont need 2 colors of cyan, 2 colors of pink, etc.. and you can redefine the palette entry to get those extra two shades of green you really need-- it makes all the difference in the world.  You just have to plan what your global color space for the full image is going to be in advance to know what ones you can reassign)

    • Like 1

  12. Posted

    On 6/12/2019 at 9:16 AM, mizapf said:

     

    Imagine you put your 90min cassette into the cassette player, and then you listen to the first transfer ... not the correct file name ... the second ... again wrong ... the third ... oh, it's gonna take some time ...

     

    But I think the C64 could use file names with its datasette (with the above effect).

    I found this rather surprising that none of these old micros though to store a special record at either the top, or bottom of the tape. (Or to make a cassette system that could programmatically rewind or fast forward the tape for that matter.) I understand that rom routine space was at a premium, but this just made cassettes so very clunky.

     

    (Then the system would know exactly where to seek on the tape for any arbitrarily written data segment.  The record would need to store tape size, then also store: file name, start index in seconds for that file, and how long the file is for each file. A load operation would read the in-memory copy of the table, see if that file is present in the table, then seek accordingly-- or prompt user to switch tape/re-read tape index, or fail.)   

  13. Posted

    Oh yeah.. I have a nice one (tales from Ebay)..

     

    Last month, I purchased a 36" wide large format printer.  The listing said 'Tested, works great!'  Yeaaahh.. Not so much. Took me 3 weeks to get it repaired.

     

    Spoiler

    What did I get from UPS?  A really REALLY tore up box (with some of the contents hanging out!), that had clearly been dropped, HARD.  While this is not the seller's fault, I inquired if they had used package insurance, because that is what it is for--- Crickets. No response at all.

     

    So, I started digging into the clearly damaged printer: Part of the cartridge service area actuator had been brutally damaged. 5 teeth on the actuator gear had been blown off from the sudden torque forces of that side hitting the floor. So, I set up some silicone rubber, cast the good side of the gear, then moved the mold to the bad side of the gear and poured epoxy.  Meanwhile I investigated why the carriage assembly wasn't moving.  Turns out the drive belt was shredded and rat-nested into the far side of the printer. Now, I could see how the chassis was cracked all to heck, and why the service station was inoperable along with all the cosmetic scuffing was from UPS being monkeys-- but not the drive belt. That thing was used and abused. The problems still kept coming though.  To change the drive belt, I had to disassemble the other side of the printer, where I discovered that the pressurized ink system (which should have been fine from a drop) was completely full of air (even tiny air bubbles in this system will ruin the print heads. This thing was completely full of air.), Screws that hold the end-clutch on the carriage slide were missing, the retention clip on the drive pulley tension mechanism was broken off, and the ink-tank holding tray had its mounting tabs shorn off.  To attach the drive belt, I had to disconnect the carriage and remove it (the belt clips into the bottom). That meant having to remove the trailing flat ribbon data cables from the carriage.  Those had mangled contacts on the edge connectors, and needed replacement. 

     

    I don't care what universe you live in, this printer would not have been in 'works great!' condition prior to shipping.

     

    Considering that the thing weighs over 200lbs, and is quite bulky even when packed up (AND that I would have to spring for proper packaging), I was not about to return it. I was merely curious if the seller had gotten package insurance.  After tearing into the thing though, I could tell that the seller was a filthy liar.

     

    ~400$ of parts later, A manually bled and reprimed ink system, and lots of cursing later-- the printer now works. 

     

     

    • Sad 1

  14. Posted

    8 hours ago, matthew180 said:

    The text modes limit the tiles to 6x8, so you won't get get 320, you end up with the same 240 horizontal pixels in T40 mode, and 480 horizontal in T80.  However, you don't have the same tile color capabilities in the text modes as in the graphics modes.

     

    The 9918A, and thus the F18A, do not work that way.  There is no "bitplane" being held in memory anywhere that can be used to modify existing pixels during subsequent frames.  The 9918A family is a table-based VDP that builds the image on the fly.

     

    Where is this iterative image held between operations?

     

    This requires more RAM than the 9918A or F18A has.  The MK2 will have the RAM, and in that case the host system would just have direct access to any such memory, it would not be exclusive to the GPU.  The GPU would certainly have access to this RAM too, and could be used to do any sort of pixel operations on the screen.

     

    This was a request a feature (for the MK2), no?  I am well aware that the TI's hardware (and the current F18A) does not have such features.  And, again, I would only need 2 bit color for the char being passed-- The transparent color, and the active color for the brush. 

     

    The idea was to get around having to map such a large section of the GPU's innards into the TI's video memory area.

     

  15. Posted · Edited by wierd_w

    Hmm.. I am a reasonably talented pixel artist (but a rather crappy programmer, sadly)-- Being able to have hardware manipulated 256 color sprites would be fan-****ing-tastic.  Telling the GPU to move sprites around, or to composite sprites/chars, would be a reasonable tradeoff for a quality indexed color mode. One of the things that always put me off qbasic programming was the lack of quality sprite routines. (NO. PSET is NOT good! There is no reliable way to move the sprite while easily retaining the background untouched without resorting to endless cycles of peeks and pokes! that defeats the purpose of using basic!)

     

    I have a game concept in mind that I would like to flesh out.  I would love to do it on this TI I picked up. I could do quite a lot with composited characters, if that was an option. Sadly, it currently is not, and the stock graphics chip has... some nasty limits.

     

    I really should set my avatar to one of my pixel art doodles.  I think I will do that now actually.

     

    Edit: DONE 

    That is 16 colors. The default ones MSPAINT offers. I could probably write a routine that could generate that image using layered characters, if the VPU supported doing that. (EG, write a char with a single BPP and two defined colors, one being transparent, with the option to composite rather than obliterate the prior char.)

     

    Edit again:

    I should probably explain what I mean better.

     

    Suppose I wanted a 320x240 mode at 256 colors. This would require an addressable bitplane that is ~77kb! This is outside the realm of reality on the TI.  Or-- IS IT?

     

    Suppose instead that I requested a 40 col X 30 row text mode, but with some flags I could tell the GPU, with the GPU holding the bitplane.  Specifically, I would ask for these flags:

    1) Do not overwrite transparent color

    2) DO overwrite transparent/background color

    3) Hmirror char on placement

    4) Vmirror char on placement

     

    I could draw the same images as a fully addressable 320x240 bit plane, but do so with a FRACTION of the system ram, just iteratively.  I could define useful pixel patterns as chars, then put them down in a specific sequence, and be able to produce any arbitrary arrangement of pixels on the screen.  For static backgrounds, this would be a nice compromise. I could do a lot with that.

     

    Specifically, I could abuse the empty space character after doing draws, to redefine characters on the fly without distorting the image. (From the TI's perspective, all that is written there is a blank space! We set the "Do not overwrite transparent color" bit, so the GPU keeps the data as composited in its internal bitplane while we redefine some more chars to do any specific operation!) I could theoretically draw *ANY* 256 color image with 2 characters, and enough time. (Write the transparent char over that position, but hold "do not overwrite" high, then redefine the brush char for the next composite step.)

     

     

     

  16. Posted

    I seem to be monopolizing this thread. :(  Surely I am not the only one interested in better tape handling?

     

    All the same; I think I want to re-write this indexer. It has several noteworthy things about it which I find problematic. (and/or, that I think would be very useful to add.)

     

    1) Placement of the index data on the cassette.  Putting it right at the start of the cassette is squicky. It makes the user have to either seek past it reliably (not so easy without a tape counter), or do an "Error 50" tape read before getting to the tape indexer.  Better is to have the indexer FIRST, reliably know where to seek to the index in the indexer, and then read the index. That way you load the indexer like a normal cassette, it prompts to rewind, then to fastforward, then to play-- It can then get the index every time, the index program never gets overwritten (It's effectively a "zero'th index"), and things are happier overall.

     

    2) It uses fixed indexes.  Not all programs are the same length, and this is wasteful of tape. We are loading a data structure from the tape; why not store how long the program is expected to be? (We know how large the loaded program is after all... We can make this determination.) We can then get reliable results with less wasted tape.

     

    3) The program is effectively counting seconds while fastforwarding, AND knows the effective times to fastforward to reach an index.  We can give a useful indicator of progress. Why not give one?

     

    4) Why not store what length of cassette this is in the index? We can use this to better judge how many indexes are sensible to make available.

     

    5) Why only 10 indexes? As long as there is sufficient data to correctly seek, we could have an arbitrary number of indexes.

     

    6) With some work, we could compile this as an assembler routine to get the cassette to be handled more like a (very slow, with user interaction) disk device as a callable handler. (The index data structure would be equivalent to the root directory entry on a diskette, containing lengths and FF-time-locations on the cassette for arbitrarily named files.) Initially loading the tape with OLD CS1 would load the TI BASIC loader, place the binary handler into a suitable section of RAM, call INIT to register the handler, then prompt to read the cassette's index.  After that the user could one-shot off the command line, with something like OLD CS1.MyProgram.  The TI would KNOW where to seek to on the cassette to load that file (Since it is in the index that was loaded, and stored by the handler routine when it was registered), would prompt the user to do the necessary steps to rewind, then fastforward, then play, appropriately-- and the program would get loaded correctly.  We would need to add another handler to update the memory-resident index when the user changes the cassette though. ) Such a handler would allow diskette based games to be adequately (If VERY SLOW to operate on data reads) run from a cassette without modification. 

     

     

    • Like 1
    • Thanks 1

  18. Posted

    Reading between the lines, I get the feeling Tursi means that if you want this product so badly to go into a second production run, he doesnt want any part of the promotion or negotiation process. (I get the feeling the last cycle took it all out of them?) That would include reaching out to another publisher; They are implying very strongly that they would like for one of us to do that instead. *shrug*

  19. Posted

    I don't live in the central texas area (two states north of there), but if you guys want any large printed materials, I happen to own a 36" wide format printer. I don't have a terribly great selection of paper on hand, but I can offer at least bright white paper, with color images up to 600dpi @ up to 36" wide. (Black and white halftone up to 1200 dpi) The post office is just down the street from me, sending a run out wouldn't be that difficult. I would just need cost of consumables + postage.

    • Like 1

  23. Posted

    I would verify that your TV is able to properly accept low resolution video.  This is a common problem, especially with newer TVs, and affects a great many devices.  My sony PS2 is affected as well-- I have to use a special hardware upscaler with it.

     

    If you have an old C64 composite monitor, or some old CRT TV laying around, I would try there first to be sure you aren't chasing ghosts.

  24. Posted

    Which is kinda silly, since the Amigas of the same era could do real-time NTSC compositing. (Course, it was all tricks with the NTSC signal generator chips, but still.) They both used 68k series CPUs.

     

    About the only kind of "input" the all in one early macs had was the "Processor Direct Slot", but I do not think any capture cards for things of the color classic era exist. The soonest  see capture cards is in the PowerPC era.

  25. Posted

    34 minutes ago, LASooner said:

    I agree, you need a Final Grom to get the most out of the TI

    I am looking forward to mine.  I am eager to start trying to program this beast, and being able to make a custom cart image quickly and easily looks handy as hell.

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...