wierd_w
-
Content Count
1,621 -
Joined
-
Last visited
Posts posted by wierd_w
-
-
14 hours ago, DragonGrafx-16 said:I would actually love to find a three button mouse without a scrollwheel but is a laser or optical mouse for my DOS PC...
HP used to make such things.
You can occasionally find them on ebay.
-
If I find I need replacement parts, I will certainly look them up.
-
Pretty much. Hilariously, even a PC's floppy controller can produce a mac formatted floppy. (ARDI Executor, and FUSION PC emulator both had capabilities to do this) This is of course, with the HUUUUUUGE caveat that the PC floppy controller will never, ever, in a million years, be able to read or write GCR., and thus will never be able to make an 800k floppy.
But still-- To be further educational: Hard sectoring was a thing that was done with 8in and 5.25" diskettes. On a soft-sectored disk, there is a single hole used to track a full rotation of the disk cookie. On a hard sectored disk, there are multiple such holes.
These are read using an optical pickup through a tiny punched window in the disk sleeve.
On a 3.5" diskette, there is no mechanism to track a full revolution of the disk cookie (in the diskette itself). Instead, there is a small magnet affixed to the side of the drive motor that spins the cookie, which is picked up by a coil winding. When the disk is spun, this is registered by the drive's electronics.
As such, all 3.5" diskettes are technically 'soft sectored'.
-
2
-
-
I just clicked the 'buy now' button on a unique bit of kit.
Specifically, a unique floppy drive.
(More information, for those needing more than just the product manual.)
(I happen to have a Brother electronic knitting machine that uses them, that is lacking the drive. I decided to finally get one.)
It is a (potentially, it also can use a wall-wart power plug) battery operated FM encoding 3.5" diskette drive, that communicates on a modified RS232C interface. It is one of the short list of devices I have considered suggesting in the various CC-40 accessories threads in the new subforum, (and as the topic has come up). Given that its communication system is so simple, a micro controller could easily sit between it and a CC-40, turning it into a swanky hexbus compliant disk system. Since such projects have recently come to exist (with FOSS code for microcontrollers to communicate with hexbus master controllers in the wild now), and since I just ordered one, I thought I would bring this up again. (Granted, it only holds 100kb/disk, and likely uses 720kb diskette media, but it isn't like the CC-40 is a powerhouse of spacious RAM to put data into to begin with.)
Now, I have no intention of using it in that capacity, since I DO happen to have a perfectly good knitting machine in need of the drive.
I do not have a CC-40, nor a hexbus interface
for my 99/4A-- But this is the OT thread, and the OT is that I purchased one of these drives.
-
Lightweight IRC implementation would be doable I think.
-
2
-
-
They saw the likes of the C64, and how it was stomping in europe, and they wanted in on the 'home market', but did NOT want the home market to bleed out the business market.
The red-headed stepchild of the PCjr was thus created.
-
3
-
-
50 minutes ago, bluejay said:IBM PCjr. Why didn't they make it 100% IBM compatible? Why did they use the awful infrared chiclet keyboard? Why did it use cartridges? Why does it even exist at all?
Mindset and TRS-80 Model 2000 (Tandy 2000): why the 80186?
If they made a budget, fully 100% compatible home PC, it would have undercut the IBM PC market, and they knew it. If it was 100% compatible, and a lot cheaper, businesses would buy the cheaper option.
By making it into a kiddie, chickletized horror that nobody could do real work on, they ensured that would not happen.(until the clones opened that bottle FOR them)
There WERE some interesting things about the PCjr though, like the cartridge slot, which was able to completely override the internal ROM. The only thing really missing from the cartridge slot was the -WE- line. Had they included it, then EMS solutions for the PCjr would have been painless, along with other memory mapped IO solutions.
-
2
-
-
SoundBlaster was a DeFacto standard; A limited subset of hardware IO ranges, IRQ and DMA addresses, etc-- for a specific configuration of sound hardware, and what that hardware expected.
Things outside that sound hardware specification, however-- such as a CDROM interface, would still need drivers, even with a jumpered card.
As for a legit soundblaster clone... If you can find one, you could invest in a Snark Barker.
-
1
-
-
Ideally, I need to get my horrible hairy hobbit fingers on a photogrammetry wand, and shoot some point clouds of all the peripherals.
They just cost too damn much for somebody on my end of the poverty axis.
-
1
-
-
I remember shipping floppy diskettes, carefully suspended on air pillows, lodged inside an overnight air express shipping USPS box.
I went through all that trouble, *BECAUSE* I had mental images of a postal worker rolling it up like a magazine, if I had used flat-pack bubble pouch shipping, and BECAUSE I had mental images of them stacking a horribly heavy stack of boxes on top of it, and smashing the media.
Thankfully none of those things happened, and it arrived on time. However, I took no chances.
Then again, Omega should already know how heavily I overpackage things I send in the mail, even when they are durable goods.
-
1
-
-
The really cool shit would come from being able to bankswitch pages of memory between the VDP's pool, and the 32k area pool.
EG, if that memory was dolled out from a single physical source, and just allocated to a specific pool by some circuitry that could be reconfigured on the fly. (eg, a 16kb window into the larger RAM area, is the "VDP Window" that we give to the VDP, while the SAMS memory gets 4 such windows of 8k size, but ultimately it is the SAME memory, physically. This would enable the DMA controller to write directly on VDP memory, behind the VDP's back-- or just switch out the whole region really fast while the next page of VDP memory is being worked on, etc)
I would think your video solution would get a tremendous boost from having memory get scribbled on by an outside controller (memory is not owned by VDP yet), then the VDP updated wholesale 16kb at a whack with a page flip.
You could only really do that if you routed the VDP socket outside the system, and did not connect the socket's RAM leads to the memory on the motherboard. (instead, satisfying it with your bank switcher, from the switchable pool)
-
1
-
-
OK, then one would need to latch the whole damn sidebus, and route the VDP socket out the side, like the mechatronic card, implement a replacement 16k VDP memory on the card, and THEN use a microcontroller to handle the DMA operation(s)
(eg, unlatch both data and address buses, bankswap or DMA VDP memory by having raw access to it, since it was moved outside "the mechatronics way" with a ribbon cable, and accomplish that by being the very first card on the sidebus. 32k or SAMS lives right after it, and any CRU bit jiggling, et al, to manage the SAMS with the DMA would be done by the microcontroller on the card, while the TI waits for GREADY)
If the GROM-acting circuit operates like a GRAM, the byte written could be used to issue one of 256 'instructions' to the microcontroller, and thus enable control over the fake DMA. It could return a status byte about any bank switched states, if last operation succeeded, et al, when read.
Then, as far as the 990 is concerned, "nothing happened", and any changes are "magic".
-
If you really need 8 bits wide, simply for the speeds needed... A stripped down 8bit PATA would work.. It would just be un-fun to implement.
As for a potentially dumb question...
We don't have a DMA mechanism, but I remember reading that when the GROM is accessed, it needs to assert the GREADY line before the CPU can/will respond. This means the CPU is in a state that is actively ignoring the data bus. (and possibly the address bus? At least, part of the address bus?)
If we implemented a circuit that is accessed like a GROM (done blindly, since we will be abusing GREADY to keep the 990 CPU in a bus-ignoring state while we do the fun stuff), we can catch the GROM access as the mechanism to initiate the DMA operation, then assert GREADY when done, and return a status byte from the GROM read, indicating an operation status. (Success, Failure, and lots of reserved)
Since the sideport has MEMEN and pals, we should be able to grab the memory bus away from the 990 and do the reads/writes, while the CPU is waiting for GREADY. (At least, the significant bits of the address bus not utilized by the GROMBASE)
Is this just idle silliness, or would that be actually doable?
It would DEFINITELY be doable, if we abstracted the 32k memory area behind a gatekeeper circuit controlled with the fake GROM circuit. (because then we could unlatch the memory, fiddle with it without raising lines that go to the 990, latch it back, and then raise GREADY)
[Yes, I realize this would not be any at all useful for the VDP's memory. You would need a circuit sitting underneath the VDP, to catch all its accesses, similar to I think, how the mechatronic 80col card did things]
-
1
-
-
TI controlled LED lite-brite
(made with tricolor LEDs)
-
2
-
1
-
-
No, I mean PLA will soften to "stretchy" from exposure to hot tap water.
Hmm... Now I wonder about lining the back with a sheet of silicone impregnated parchment paper... Poke the components through, like a light-bright, THEN solder... Hmm...
Maybe a sheet of silicone rubber matting?
-
2 hours ago, HOME AUTOMATION said:What makes you so smart?
Do you think animals have feelings?🐱
Which supermarket do you do your shopping at?🛒
Do you think there will be any looting?💎📺🎥🎸🚲🍸🍺👙
Do you think the bar-chart should go vertically or horizontally?↕️↔️
Should I turn off the cooling pumps, to keep the reactor from going solid?☢️
Smartass mode ENGAGED!
No idea, why? Looking to improve?
Of course they do. They (typical vertebrate animals people think of, discounting things like mollusks, bugs, et al that are most certainly not vertebrate animals) have fully developed limbic systems. There is no conceivable reason why they would not have feelings.
Mostly walmart, due to convenience. However, I DO grow my own produce each year...
Probably not. At least, not at the one I shop at. It has a very low patron rate, and is very uncrowded. The community it is in is likewise, very quiet.
Silly plebian, a quality chart is information dense, and easy to read. A scatter plot with BOTH axes is the proper response!Turning off the coolant pumps on a fission reactor is pretty much universally a "Bad Idea".
-
1
-
-
How does it not get all messed up when you solder the back then?? PLA melts at absurdly low temps....
-
I was thinking more of the idea, that since it is digital level data, you just ignore the overhead, and send "thicc" signals.
eg, send a long pulse of 1 state, and then a long pulse of 0 state, etc.
Eg, instead of transmitting "1", and expecting the TI to catch it (laughable), you send a deluge of 1s, for a duration acceptable for the TI to catch. The signal will probably be a bit noisy, so use an inductor tank to keep it high for a long enough duration while the 1s are shooting through.
eg, instead of using the CDDA data to store raw bytes, you encode your byte across many multiple bytes.
eg, instead of
10011010
you send (since you said 20 bit values, here's 24 bits expansion)
111111111111111111111111000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111000000000000000000000000111111111111111111111111000000000000000000000000
and abuse the frequency response falloff of the inductor to keep it high while the 1s are going through.
It means the amount of data storage of the CD is brutally smashed, but reading the data is easy.
-
2
-
-
2 hours ago, Omega-TI said:Woo Hoo! The package arrived today! Now I need to find a COUPLE of suitable and fun projects. The "classic sized" one is cute, and I'll use it, but the "modern deluxe" one is great too! Decisions, decisions! Anyway, here is the video as promised.
What is the gridplate made of? Is it something like colored phenolic, or is it just common garden-variety plastic?
I have considered something "similar" as a 3D printer project, for board prototyping. Grid pattern on one side, subtly done "channels" to run bus-wires through on the back.
-
1
-
-
1 hour ago, HOME AUTOMATION said:Like this one...
Direct CRU I/O, should be capable of better speeds than the cassette port.
Yes, Exactly.
However, for the purposes of CRU IO, I would think you would be better served by a 5.25" enclosure, and old IDE drive, and a 2 wire SPDIF cable. The signal you would get from the "audio" would be fully digital levels that way, and would be easier to work with electronically. Some very limited subset of IDE logic could be used to instruct the drive what track, and timestamp to do playback from, with the SPDIF output going to your CRU-IO logic.
Re: VDP is the problem
Depends on how you decide to go about it. Take for instance, Tursi's video solution (as found in Dragon's Lair). You just need to get char data in fast enough to handle the mode-switching magic's requirements. If you were to abuse the SPDIF interface to just blast in digital level data, and get it right from the CRU bus, you could conceivably get it in fast enough to satisfy the requirements.
-
3 hours ago, HOME AUTOMATION said:Back around '99, I used a program that could record/compress MP3 audio on-the-fly. I used it to record NASA STS mission audio. I seem to recall getting 1 week worth of mono FM broadcast quality sound onto a CDDA disc. Even on the cassette port, that could probably hold-it-all.
I think CDDA can handle a square wave. If so, the audio could be fed directly through CRU I/O, connected to the joystick port.
In the LATE 90s, there were discman knockoffs that could play MP3s on CD.
Integrating one of those would be relatively straight-forward. Still would be slow to load the data, and would make lots of noise. Better to just use the TIPI.
As for what CDDA *IS*-- it is *JUST* uncompressed PCM. PCM is by its nature, just chunky approximation of a sinusoid waveform. Strong, full oscillation between states (consistent with square wave) is totally doable with PCM.
-
1
-
-
That is like a tarot card's The Tower... Both imply it will hurt a LOT when it falls on you.
-
3
-
-
I have done some initial testing, and I can get the arch package for that minimalist GTK based graphic default sound device selection app shoehorned in. (it's basically just a gzipped tar, containing a python script and some support libs)
The issue I have, is that my chromebook has....... "Nonstandard" ..... audio hardware, that needs a special firmware blob.
I am thinking I will need to integrate audio firmware in the image as well.
A dirty kludge could be to use TTY2 as another GUI panel, with the sound picker running. Then use TTY3 for the root console.
-
1
-
-
12 hours ago, AwkwardPotato said:Implementing SPI does not have to be this complex. No 512-pin breakouts or latches or buffers are needed -- the sensors/displays/etc will not compete for control of the SPI bus, since the AVR will only ever read/write to one device at a time.
Theoretically, to implement this you'd connect the 3 SPI lines (SCK, MOSI, and MISO) from the UberGROM's AVR to each SPI device in parallel. Each device does NOT need its own SCK/MISO/MOSI. An individual Chip Select for each device can either come straight from the AVR, or from a demux if you run out of I/O. If I'm not mistaken, the UberGROM could use the READY line on the cartridge port to slow the TI down for slow SPI accesses.
With this method, you would need a total of 7 wires coming out of the cartridge for 4 SPI devices. If you wanted even fewer wires than that, you could use I2C instead of SPI, allowing access to up to 128 devices with only 2 wires.
The intent with the large number of latches was more to catch the returns of many connected devices after switching focus. The idea was to get the most bang out of the slow speed of the bus, by not requiring focus to catch the last written byte. You can fire off a transaction then switch focus to the next device, and the buffer will catch the device's response, while you work with the next device on the chain.
The intent was more like with HomeAutomation's love for talking with sensors. He could fire off a queue of "Give me the temperatures in all the rooms" outputs, the sensors all respond, then he can collect and handle the returns sequentially, by moving the focus over the latched returns.
Otherwise, he has to do a full transaction sequence with each sensor.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Formatted diskettes
in Classic Computing Discussion
Posted
The phenomenon was well documented back in the day.
The suggestion was to bulk-erase the floppies, so that the media was randomized again. Apparently, the data signatures from GCR floppy sectoring were very difficult for the MFM formatting process to flatten (magnetically), and this lead to all manner of problems. (and vice-versa.)
These days, since I lack a good bulk erase wand, instead I have an ingenious plastic clip to hold a neodymium disk magnet in a dremel tool's bit retainer, and spin it around at high speeds. Works OK for floppy media at least.