1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-12-25 18:30:21 +00:00
Commit Graph

146 Commits

Author SHA1 Message Date
Thomas Harte
8499783b14 Dragged multibyte primitives and signature checks up to the base class. Implemented support for Oric MFM-style .DSK, at the file format level. 2016-11-21 20:47:16 +08:00
Thomas Harte
31c2548804 Created a base class for the boilerplate fopen stuff, switched as many classes as possible to its use, switched to postfix underscores and non-camelCase names. 2016-11-21 20:14:09 +08:00
Thomas Harte
97811fe590 Made minor fix to ensure that a header that appears to extend beyond the end of an Oric .TAP doesn't create an ostensibly endless tape. 2016-11-15 12:02:03 +08:00
Thomas Harte
fce48b9b8c I am instructed that the Oric actually catches only positive transitions, and compares the distance between those to a threshold. So here's an altered version of the tape parser that does that. 2016-11-09 06:37:10 -05:00
Thomas Harte
c257e7f58d Implemented better sync-to-zero and discovered a header counting bug plus, probably, a misleading representation of gaps in the Oric TAP decoder. 2016-11-07 20:17:06 -05:00
Thomas Harte
80702616ea Had a quick go at using the Oric parser for static analysis. Found out that synchronisation is lost. Need to investigate. 2016-11-06 22:56:38 -05:00
Thomas Harte
7205c3f82b Made an attempt to build in Oric slow/fast detection. 2016-11-06 21:31:10 -05:00
Thomas Harte
d1ef2f7c63 Made an attempt to consolidate what I learnt of Oric encoding while building this hastily and untidily directly into the Oric implementation.
(while adding support for the slow tape encoding mode)
2016-11-06 19:22:09 -05:00
Thomas Harte
353c1c8ea3 Shifted ownership of PETSCII -> string conversion down to the storage layer, where it's useful for tape parsing. 2016-11-06 18:43:51 -05:00
Thomas Harte
1b15bc3a6c Started relocating the tape parsers down from static analyser to storage, to signify that they may be used by the emulation (if fast loading is supported on that machine). 2016-11-06 16:13:13 -05:00
Thomas Harte
827a919368 This is an initial attempt at reading actual tape data. It loses sync though. 2016-11-02 22:30:53 -04:00
Thomas Harte
d3634488e6 Made an attempt better to deal with multiple-file TAPs; also started using a zero level for the header/data gap. 2016-10-24 21:59:06 -04:00
Thomas Harte
cbbd31c2e0 Explained what this recently factored-out class does, and removed code from the header. 2016-10-20 19:33:25 -04:00
Thomas Harte
cc0b70828b Removed attempt at multiple-file logic, at least for the time being. Starting to wonder whether I actually need anything beyond a literal streaming of bytes? 2016-10-16 22:15:24 -04:00
Thomas Harte
fae1bb0db9 First successful game loaded! It turns out exactly one '$' is correct. Probably. 2016-10-15 21:49:41 -04:00
Thomas Harte
952a24f769 A quick hard-wiring of the OricTAP code to get the first file in a .tap correct, damn the rest, and I'm getting some on-screen feedback. Hooray! 2016-10-15 21:39:53 -04:00
Thomas Harte
a608bbebfb Performed enough wiring to put the onus back onto OricTAP to do appropriate things. 2016-10-15 21:32:59 -04:00
Thomas Harte
6d7c3f6ac2 Factored out the now-sampling binary-level tape player from the Vic and connected it up to the Oric. 2016-10-15 21:21:18 -04:00
Thomas Harte
4f78d693e9 Reintroduced gap as a string of 1s, made an attempt to look up bit ordering. Still unclear on high/low versus low/high. 2016-10-11 08:07:51 -04:00
Thomas Harte
70f004efbb This may be feeding bits in the wrong direction or calculting the wrong parity or doing something else amiss but should now be correct as to bytes. 2016-10-11 07:57:10 -04:00
Thomas Harte
df01c78039 It's a bit of a mess but this is probably close to appropriate for Oric TAP files. 2016-10-11 07:39:48 -04:00
Thomas Harte
abf47efd40 Factored out Commodore is-a-ROM test, allowing it to be used from the Commodore analyser and thereby allowing ROMs to get as far as the machine again. 2016-09-29 19:39:13 -04:00
Thomas Harte
4010f36238 Ensured tape-formatted PRGs reach a conclusion. 2016-09-29 19:12:26 -04:00
Thomas Harte
ca53fac732 Switched to assuming a single-sided disk, moved out magic constants. 2016-09-26 21:20:30 -04:00
Thomas Harte
572d5587d9 Made a first stab at enabling multi-disk machines and thereby obeying (some of) the Plus 3's status register. 2016-09-25 21:24:16 -04:00
Thomas Harte
9bbcbd1001 Renamed class, intending to turn a Disk::Drive into literally just that, and have a thing with a PLL that consumes events be a Controller. 2016-09-25 20:05:56 -04:00
Thomas Harte
523dbb9678 This'll do for getting the ADF into the machine. 2016-09-25 18:32:26 -04:00
Thomas Harte
de863719d0 Made a first attempt at Acorn ADFS support plus the start of a suitable analyser. 2016-09-25 17:46:11 -04:00
Thomas Harte
a9e65e9b7a Tweaked disk side density, added call-outs to a WD1770 if the Electron had one (albeit without run_for_cycles yet as I need to figure out the clock rate), added a shell of the basic functions of the WD1770. No implementation yet. 2016-09-19 22:06:56 -04:00
Thomas Harte
64f2538b1f Added CRC checking to DFS comprehension; fixed a bunch of places where I'd used Objective-C's #import rather than #include. 2016-09-19 08:16:06 -04:00
Thomas Harte
8a1b805d11 Fixed file offset calculation for single-sided images. 2016-09-19 07:34:10 -04:00
Thomas Harte
b1e7f2dfd0 There's no cache and no CRC checking yet, but this is probably a rough outline of an FM parser. 2016-09-18 22:03:06 -04:00
Thomas Harte
d1c861d3a5 That should be that, I hope. 2016-09-18 21:09:32 -04:00
Thomas Harte
02c9a82cb5 Edging towards SSD/DSD support. Hold on! 2016-09-18 19:32:08 -04:00
Thomas Harte
91cd7e143b Started on the SSD/DSD support. Realised I had ommitted multiple head support from my disk class. Fixed that. 2016-09-18 19:21:02 -04:00
Thomas Harte
5409c8ec54 Switched PCMSegments to std::vector; ensured generated [M]FM tracks are correctly sized, thereby making sure the individual flux windows will be correctly sized. 2016-09-18 18:56:35 -04:00
Thomas Harte
d9aaf456f0 Adapted pervasively to MSB-first output. Which seems to be correct. 2016-09-18 18:46:58 -04:00
Thomas Harte
180c3df2d4 Calling it 'number theory' probably isn't accurate but extracted the CRC stuff and started using it for [M]FM encoding. 2016-09-18 18:33:26 -04:00
Thomas Harte
55a7418cbf Parameterised to perform FM and MFM encodings, at least subject to CRCs still being missing. 2016-09-18 17:16:20 -04:00
Thomas Harte
22eed60d2b Started sketching out basic MFM track encoding. Which possibly even means that the shifters don't need to be public? 2016-09-18 16:53:21 -04:00
Thomas Harte
0089c830c6 This possibly correctly encapsultes the lowest level of FM and MFM rules. 2016-09-18 14:17:06 -04:00
Thomas Harte
bcf91de7e9 Declared support for the Acorn disk files, started hammering out an encoder. 2016-09-18 13:35:54 -04:00
Thomas Harte
6454508db8 Added a quick bit of documentation. 2016-09-18 10:30:52 -04:00
Thomas Harte
65b568003d Clarified TODO. 2016-09-18 10:29:45 -04:00
Thomas Harte
8c2bf099ad Cut down to one GCD and clarified variable names, getting more explicit about what's going on. 2016-09-18 10:24:09 -04:00
Thomas Harte
79ef38b123 Attempted to use the new get_cycles_until_next_event method to take some repetition outside of the PLL and drive event loops. 2016-09-17 22:02:38 -04:00
Thomas Harte
dbb758aaf1 Workaround for a weird bug that suddenly appears to manifest: gzgetc is returning the file name, not bytes from the file. Seems to be related to improper initialisation of the next field within the gzFile header. I can't immediately see where ZLib intends to do that so it's a bit mysterious. But the larger-than-8 readers could probably save time by reading in blocks anyway. 2016-09-17 22:01:25 -04:00
Thomas Harte
14a9edcf5d Made an attempt to do the time base conversion upfront, saving a lot of hassle and allowing greater prediction. 2016-09-17 19:52:27 -04:00
Thomas Harte
9d6dcb80a7 Started work on a GCR parser and the helper functions that lie behind that. 2016-09-13 21:53:36 -04:00
Thomas Harte
e3571e8b9e Added insurance against an infinite loop should the tape be exhausted. 2016-09-12 22:22:23 -04:00