stardot.org.uk

Marvin wrote: ↑

Thu Jul 09, 2020 10:21 pm

The drive mounts to it's bracket with 2 screws per side, so 4 in total...
A310 floppy side.JPG

This is perfect, thank you! I guess I just didn't spot the pair of screw holes in the corner of the bracket near the front of the machine.

Oh interesting -- sounds like it's more complicated than I thought, and the connector is wired up in an odd way on the A300 series boards!

I have an A310 that's missing its floppy drive, and the diagram in the A300 Service Manual isn't awfully helpful. Screen Shot 2020-07-09 at 11.28.30 AM.png I appear to have the bracket pictured in the digram, but it only appears to have two screw holes to connect to the drive itself. Aside from the ...

RISC_PC.rom.zip Looks like a successful extraction of RISC OS 3.71 :) philp-mac:tools philp$ shasum RISC_PC.rom c5fe0645e48894fb4b245abeefdc9a65d659af59 RISC_PC.rom philp-mac:tools philp$ grep c5fe0645e48894fb4b245abeefdc9a65d659af59 hashes.txt riscos-3.71 c5fe0645e48894fb4b245abeefdc9a65d659af59 4...

Just reporting in that Board no. 4 is alive and well. Arrived today and booted straight into diagnostics no issues on my known-good RISCPC600 =D> =D> Thanks @myelin Have now left it reading the ROM contents... Great! Whoops... looks like I left read_rom.py in the repository. That one uses the built...

[*]Disabling the ROM checksum temporarily (always return zero) to get the thing to boot. I believe the boot process will continue eventually, after spending ages on a red screen flashing out the error code with the floppy light. That was my experience when running RO 3.20 on an A3000. As for whethe...

Is it possible to pare this back, a la the "Roll Your Own RO3.1x" thread (https://stardot.org.uk/forums/viewtopic.php?t=14164)? Ideally I'd like to build 3.11 (or 3.19) with Wizzo IDEFS in ROM, with as few changes to the original ROM as possible. Although I appreciate it'll be a 4MB ROM. Meanwhile ...

Turns out my A4000 has the silkscreen the right way round. My cable flipped the pins 1->6, 2->5, etc. I've changed the cable out for a 1->1 wired one with colour coding... :shock: I use "DuPont" cables from Aliexpress that rotate through the resistor color code, with red as pin 1 / +5V, through pur...

Thank you! Will PM -- you'd be surprised that Royal Mail postage to the USA isn't too pricey. Happy to cover the costs of course!

This is really cool! I don't suppose I could buy a set off you, could I? (Or if anyone else here has a 3D printer and would be able to print me one.) I'm trying to mount a Gotek in the lower drive slot in my A5000, and looking for something a bit sturdier than the pile of cardboard and tape that was...

Not quite sure where to post this, but as the application for these chips is most likely level conversion for 3.3V systems, I thought this thread was probably the place. I used a 74LCX125 to convert 5V signals down to 3.3V for my USB POST box , because it has high impedance when unpowered -- i.e. vo...

anightin and steve3000, your boards are in the mail! Some early test data is back from philpem, who has been using his board... so one big thing is to be extra careful about the cable wiring, as this has no reverse polarity protection (or, well, the static protection diodes in the 74HCT125 and 74LCX...

stevebubs wrote: ↑

Thu Jul 02, 2020 12:51 am

Please could you add me to the list. Have a few machines that could do with a bit of TLC.

Added!

IanS wrote: ↑

Tue Jun 30, 2020 11:36 pm

Looks like a useful addition to the toolkit. Please add me to the list. Thanks.

Added!

KarateEd wrote: ↑

Tue Jun 30, 2020 10:53 pm

I would love to have one of those. I see you probably would have to do another run but count me in if you do so.

That's the plan! I'll update here as components arrive and boards get built

Sounds awesome. I take one if shipping to Germany is possible. Shipping to Germany is no problem :) You're first on the list after the two priority testers. I'd like one please, if it's not too late. Not too late at all! I plan to do this as a continuous thing, making a few boards at a time and slo...

Great! Looks like there's enough interest to use up all the PCBs I have here, and if this continues, do a second run. philpem sent some notes from his initial tests and there's a couple of things I'd like to get more info on, so the two boards I have right now will go to anightin and steve3000 for m...

An update here: It worked! I have a Gotek set with the "ibmpc-density" drive type, and it seems to work quite happily plugged in to PL11. It enumerates as :0 despite being on SEL3, so what I'd heard about drive numbers appears to be correct: RISC OS numbers drives from :0 as it finds them, stopping ...

hoglet wrote: ↑

Tue Jun 30, 2020 5:33 pm

I've not been too well today, so I've not had a chance to try any of this yet, but hopefully I will tomorrow.

Hope you feel better soon! I won't have any time to touch this until Friday (when I'll get back to Verilog porting, I think), so no hurry

I've been using this quite a bit on several different machines, and it seems pretty solid. philpem has the first one and will undoubtably have more to say soon, but I think it's safe to start making more of them for others. I've thrown up a post on the "for sale" board ; and will assemble these a fe...

As seen in the Acorn "POST box" display adaptor (0086,804) thread, I have designed a PCB with an FPGA running Phil Pemberton's POST interface, plus a USB microcontroller that provides a communication channel to let you fully interface with the self-test code present in RISC OS 2.01 - 3.70. This lets...

And this appears to work! With this commit , flash accesses should now take 146 ns -- that is to say, flash_nCE is low for that long; there's probably another 11ns to get the address registered. And here's the first VHDL to Verilog port, sdram_simple.v . Mainly a mechanical thing using vhd2vl with s...

Working on the flash now... I've pushed a few commits to GitHub that tidy up qpi_flash_test.v a bit, remove the delay at the end of each SPI/QPI transaction, and make flash_SCK run continuously. This seems stable. To do now: - (done) Increase the number of dummy clocks from 2 to 6, to handle the hig...

It turns out the FLASH read data is actually taking about 500ns to arrive, leaving almost no data setup time. Why so long? I drew a couple of timing diagrams and discovered the following: - lets call the falling edge of clk_out (Phi0) time t=0ns - the wait_for_ads_counter counter is reset at t=80ns...

Perfect; I was hoping to just port the whole thing over then continue in Verilog, so it sounds like we’re in agreement :) About T65, I’ll probably just use something different for testing for now, but maybe try to port T65 itself later on. I’ve pulled your latest work into my fork on GitHub and will...

That’s interesting that the block ram isn’t returning data quickly enough! Feel free to remove the synchronization if it works without it; I put that in because feeding external signals straight into block ram felt like a bad idea, but if it seems stable, it can run async for now. I have a 4MHz 6502...

Excellent work! You may have to mess with the flash and sdram timing to get it to work with an external cpu. The flash in particular may take too long to access, and it might latch the address right after the falling PHI0 edge (and I have no idea what AdvanceExternalClock will do in that case — it’s...

Good idea! I already did all the soldering last night anyway, but for anyone else: it looks like the A30x0/A4000 just wire the Mtr0 and Drv0 pins from the 82c711 to pins 16 and 10 on the drive connector. I wonder if I’ve gotten the wrong FDD pinout in that case, as that looks like Drv0 and Mtr1 by t...

Oh this is great progress! Well done and thanks for writing up! Ior* is a really interesting finding, and definitely worth a look on other failed PCBs. As is IC36, which is just within the danger zone from battery leakage. Thank you! I should attempt to tidy up these notes, and post some pics of my...

Indeed, and it wouldn't explain with it is fine when it's always running at 2MHz. It's something perculiar to the clock switching. Another thought... is it possible that there's another bug, and accesses to &FCxx are being performed at 2MHz? That would mess with the 6522 code, I imagine. I'll give ...