So... Making progress. Firstly, I understand the options string and how that turns into bits. there's only 32 of them, tho --- given other things I've stumbled over, that is terribly few. I've complained elsewhere about the lack of bits.
But "cartridge.v" ... fascinating. Obviously, there aren't on screen menus for this. I haven't sussed out everything yet --- do the cartridges just key of some bytes in the cart file for their format, or is this a bunch of functionality that isn't implemented in mister?
As I said before, my end-goal here for the project is working REU (RAM Expansion Units) like the 1750.
That said, there's a long tradition of having more than one cartridge active at a time. Luxury of having slow-ass clock speeds. Anyways... that doesn't appear to be contemplated here? Discussion?
A matter of Bits and Cartridges.
-
lastninjaju
- Posts: 5
- Joined: Sun Jul 26, 2020 1:04 pm
- Been thanked: 1 time
Re: A matter of Bits and Cartridges.
Which parts do you not understand? The options string is part of mister fpga... specifically tied to the OSD. cartridge.v is a file in this project's source. It's interesting because it supplies configurations for many different and specific cartridges. A 1750 RAM Expansion Unit is a thing, made by Commodore, Back-in-the-day.
My question for discussion was about how the cartridge file format may or may not select bits in that file --- so if you're not someone who has looked at the code... you can just move on...
My question for discussion was about how the cartridge file format may or may not select bits in that file --- so if you're not someone who has looked at the code... you can just move on...
-
Newsdee
- Top Contributor
- Posts: 873
- Joined: Mon May 25, 2020 1:07 am
- Has thanked: 104 times
- Been thanked: 239 times
Re: A matter of Bits and Cartridges.
You just need an OSD option to switch carts / modes. That kind of cart switching is typically part of the core itself, you can look at the options of the MSX core as an example.
Re: A matter of Bits and Cartridges.
Well... I've gained a little bit more understanding by reading the "source" .. so the .crt format is a container format ... it does specify a layout number --- which I what I was looking at. So that's one thing. I'm still not sure how the OSD "File" types work. I'd love to get some insight on where that's coded.
As for OSD menus ... I've successfully managed that --- and as for using one to pick from a list of carts --- the OSD is limited to 64 total bits for options, it seems. And the c64 is only supporting 32 of those bits (of which 3 non-contiguous bits are free ATM).
Looking over the code, there's some more things I need to understand. The cartridge.v file may not be the right place after all. The REU's only "appear" in a few bytes around $DE00 and act as a DMA engine. Heck, since the base FPGA runs at 50Mhz, there's nothing stopping the REU from pumping memory at full speed (subject to options). Anyways... the way the REU's work is not as similar as I thought to the code there.
So... if anyone can point me at how the file-type ('F' code) of the OSD CONFIG_TXT works, that would be a leg up.
I'm also looking at sys_top.v to try to understand how the ram of the mister is accessed. There, they declare:
output [12:0] SDRAM_A,
inout [15:0] SDRAM_DQ,
... which, since the RAM I have is 128M, seems like too few bits. c64.sv has:
output [12:0] SDRAM_A,
output [1:0] SDRAM_BA,
inout [15:0] SDRAM_DQ,
... in which BA might add 2 bits to A, but this still doesn't seem like enough --- even for the C64 --- where the address lines should be 16 bits (likely plus some of the 6510 IO registers bits).
... so if I could pick someone's brain on this issue, too --- would get me underway much faster.
As for OSD menus ... I've successfully managed that --- and as for using one to pick from a list of carts --- the OSD is limited to 64 total bits for options, it seems. And the c64 is only supporting 32 of those bits (of which 3 non-contiguous bits are free ATM).
Looking over the code, there's some more things I need to understand. The cartridge.v file may not be the right place after all. The REU's only "appear" in a few bytes around $DE00 and act as a DMA engine. Heck, since the base FPGA runs at 50Mhz, there's nothing stopping the REU from pumping memory at full speed (subject to options). Anyways... the way the REU's work is not as similar as I thought to the code there.
So... if anyone can point me at how the file-type ('F' code) of the OSD CONFIG_TXT works, that would be a leg up.
I'm also looking at sys_top.v to try to understand how the ram of the mister is accessed. There, they declare:
output [12:0] SDRAM_A,
inout [15:0] SDRAM_DQ,
... which, since the RAM I have is 128M, seems like too few bits. c64.sv has:
output [12:0] SDRAM_A,
output [1:0] SDRAM_BA,
inout [15:0] SDRAM_DQ,
... in which BA might add 2 bits to A, but this still doesn't seem like enough --- even for the C64 --- where the address lines should be 16 bits (likely plus some of the 6510 IO registers bits).
... so if I could pick someone's brain on this issue, too --- would get me underway much faster.
Re: A matter of Bits and Cartridges.
The SDRAM address bus is too few bits because it's multiplexed into row and column addresses, as is conventional for DRAM in general. The conventional idea is that you put the row address on the bus, strobe /RAS, wait some specified amount of time, put the column address on the bus, strobe /CAS, then wait for some more time before the data is valid (or latched if writing). SDRAM is based on this model, but reinterprets it somewhat with the concept of the control signals forming a "command". Micron data sheets are pretty good about describing this, but if you've never encountered it before it can be a lot to take in.
Realistically, most MiSTer cores are using some pre-existing SDRAM controller rather than having a new one developed specifically for the core. Usually this is either rtl/sdram.v or rtl/sdram.sv. I'm not sure there's any canonical version of this; it seems like it's just been copy/paste/edit between cores.
Realistically, most MiSTer cores are using some pre-existing SDRAM controller rather than having a new one developed specifically for the core. Usually this is either rtl/sdram.v or rtl/sdram.sv. I'm not sure there's any canonical version of this; it seems like it's just been copy/paste/edit between cores.
Re: A matter of Bits and Cartridges.
i have added in a other 6502 core , eprom source code .And it was not that difficult .put ram on that spot is almost the same .adding eprom /ram out side $0000-$FFFF i don't have expiriance.
adding a option for REU on the C64 core ,sounds for me very good.
adding a option for REU on the C64 core ,sounds for me very good.
Re: A matter of Bits and Cartridges.
OK. Looking at sdram.v, I see that it has one busy looking (but small) always block. I suppose that does it.
But then I look at T65.v or cartridge.v and I'm not sure how they access the ram. I'm also looking at c64.sv to see if that glues it.
... where do these interconnect?
But then I look at T65.v or cartridge.v and I'm not sure how they access the ram. I'm also looking at c64.sv to see if that glues it.
... where do these interconnect?
Re: A matter of Bits and Cartridges.
Navigating this stuff can be a little tedious, and does take some practice. I assume some kind of smart editor support with a "find usages" function exists somewhere, but I've never personally seen one that actually works (let alone across Verilog and VHDL), so I just use grep and the search function in my text editor. Maybe that feature is only in more expensive "real" EDA tools.
The instantiation of the sdram controller is in c64.sv here.
Disregarding the "io_cycle" stuff (which is for the Linux side to load things), the SDRAM controller's address input is connected to the "cart_addr" signal, which in turn is connected to the "sdram_address_out" output of the cartridge module here.
That signal is assigned in rtl/cartridge.v to reflect its internal "addr_out" signal here.
That internal signal is generated by this always block.
The instantiation of the sdram controller is in c64.sv here.
Disregarding the "io_cycle" stuff (which is for the Linux side to load things), the SDRAM controller's address input is connected to the "cart_addr" signal, which in turn is connected to the "sdram_address_out" output of the cartridge module here.
That signal is assigned in rtl/cartridge.v to reflect its internal "addr_out" signal here.
That internal signal is generated by this always block.
Re: A matter of Bits and Cartridges.
Thank-you. That helps a lot. I've also put together a few things --- trying to see everything that ties into c64_addr in c64.sv. So I'm getting there.
At this point it would be really helpful to have a RAM map for the SRAM. I'm assuming the first 64K is the C64's RAM... but I suppose that's not necessarily so. Other data I'm expecting to be there are the kernel and basic ROMs, the 1541's ROMs ... the character ROM, I suppose. I'm also curious how you cause the linux to load things into it (not that I need that for my stuff here, but I'm just very curious).
And yes, I too have been using grep. The IDE is Quartus Prime Lite --- I don't know that it has any symbol following. But Linux 4 windows is a passable thing as cygwin was before it. I'm curious, too, what the protocol is for using the sdram controller --- obviously we'll be cycle stealing from it --- but stuff already seems to do that.
But a memory map of the SDRAM would be very helpful.
At this point it would be really helpful to have a RAM map for the SRAM. I'm assuming the first 64K is the C64's RAM... but I suppose that's not necessarily so. Other data I'm expecting to be there are the kernel and basic ROMs, the 1541's ROMs ... the character ROM, I suppose. I'm also curious how you cause the linux to load things into it (not that I need that for my stuff here, but I'm just very curious).
And yes, I too have been using grep. The IDE is Quartus Prime Lite --- I don't know that it has any symbol following. But Linux 4 windows is a passable thing as cygwin was before it. I'm curious, too, what the protocol is for using the sdram controller --- obviously we'll be cycle stealing from it --- but stuff already seems to do that.
But a memory map of the SDRAM would be very helpful.
Re: A matter of Bits and Cartridges.
Would you be interested in working on REU together? I’ve started to look at it from a cartridge perspective. The easy flash already has the ability for 1mb of paged rom, the REU is much the same, but it has DMA and a set of registers to help bank switching and copying data around between the REU and C64 RAM. Check out the SuperCPU post in this forum. I’ve only literally started looking at this...
Re: A matter of Bits and Cartridges.
So not much progress at this stage. I believe that the way forward is to add an additional cartridge type to the cartridge module. Then, when it's attached (either via a cart file, or OSD configuration), enable reu with a signal (setting exrom and game signals correctly). The sdram instantiation would then pick this signal up and start to deliver bytes corresponding with the REU registers (df00-df0a) via a new REU module. It might be possible to use the Ultimate 1541 REU as a base for the actual implementation eventually, especially the DMA stuff.
In trying to get the sdram to deliver a different set of data when reading/writing to df00 and the specific cart_id and reu_attached set high, I get a black screen when booting the core
. I have added in some signal taps to see what the cart signals are doing, so perhaps that will shed some light on it.
I do believe this is entirely possible to pull off. It seems that the easy_flash support already has 1mb of RAM/ROM via sdram. The difference with the REU is that there is DMA and registers used to control said DMA.
In trying to get the sdram to deliver a different set of data when reading/writing to df00 and the specific cart_id and reu_attached set high, I get a black screen when booting the core
. I have added in some signal taps to see what the cart signals are doing, so perhaps that will shed some light on it.I do believe this is entirely possible to pull off. It seems that the easy_flash support already has 1mb of RAM/ROM via sdram. The difference with the REU is that there is DMA and registers used to control said DMA.
-
yellperil
- Posts: 25
- Joined: Mon May 25, 2020 2:08 am
- Has thanked: 2 times
- Been thanked: 5 times
- Contact:
Re: A matter of Bits and Cartridges.
Some one wrote this REU as well, which may be of some use for example code . . . https://github.com/zeldin/super-reu
There is also this document : http://www.zimmers.net/anonftp/pub/cbm/ ... oc-1.0.zip
The SuperSnapshot cart is also compatible with the REU and both could be used at the same time, I don't know of any other use examples so this functionality may be an outlier.
There is also this document : http://www.zimmers.net/anonftp/pub/cbm/ ... oc-1.0.zip
The SuperSnapshot cart is also compatible with the REU and both could be used at the same time, I don't know of any other use examples so this functionality may be an outlier.
Re: A matter of Bits and Cartridges.
]yellperil wrote: ↑Thu Feb 04, 2021 11:39 am Some one wrote this REU as well, which may be of some use for example code . . . https://github.com/zeldin/super-reu
There is also this document : http://www.zimmers.net/anonftp/pub/cbm/ ... oc-1.0.zip
The SuperSnapshot cart is also compatible with the REU and both could be used at the same time, I don't know of any other use examples so this functionality may be an outlier.
That super-reu is great as it's in verilog and much easier for me to work with. Thanks for that!
Re: A matter of Bits and Cartridges.
So good progress. I’ve got the registers working, including writing to the registers. This means that the REU tools detect that a REU is attached, since they usually write a set of numbers into Df02-df07 and check that those numbers can be read back. I’ve yet to test the execute bit, but will look at that shortly. I think the REU data should be mixed onto the sdram, but I know the dma signal is not being used to disable the cpu from the bus yet.
Re: A matter of Bits and Cartridges.
So executing the DMA transfer is at least happening. However, I am not seeing the correct data going into the REU (SDRAM). And certainly, attempting to transfer it back again results in nothing happening. It also looks like the state machine gets locked once the transfer is complete.
I am trying to get the DMA signal to come out of the REU code... Perhaps that needs to be set before transfers can occur correctly? At the moment, I am just getting a black screen. Perhaps because the dma signal isn't being initialised high, defaulting to active low.
- unknown.png (58.69 KiB) Viewed 9721 times
I am trying to get the DMA signal to come out of the REU code... Perhaps that needs to be set before transfers can occur correctly? At the moment, I am just getting a black screen. Perhaps because the dma signal isn't being initialised high, defaulting to active low.
-
yellperil
- Posts: 25
- Joined: Mon May 25, 2020 2:08 am
- Has thanked: 2 times
- Been thanked: 5 times
- Contact:
Re: A matter of Bits and Cartridges.
I don't think the original author of the core implemented hardware pull-up logic in any of the core.
You'll probably have to invert those what should be normally high/active low signals coming from the core at your REU interface.
The verilog code example was for a real cart to be plugged into a real c64.
Keep the updates coming, it's really interesting seeing what you are doing.
You'll probably have to invert those what should be normally high/active low signals coming from the core at your REU interface.
The verilog code example was for a real cart to be plugged into a real c64.
Keep the updates coming, it's really interesting seeing what you are doing.
Re: A matter of Bits and Cartridges.
Possibly. I have piped in a number of the signals that appear on the bus, including DMA_N, AEC, BA, PHI02 etc. The registers are obviously working correctly, as I can read and write to them to configure and initiate the DMA transfer - the transfer actually begins, it's just the REU (SDRAM) address does not increase. It looks like the c64 address is actually increasing, but I cannot tell if that's resulting in reads from RAM.yellperil wrote: ↑Sun Feb 21, 2021 12:19 pm I don't think the original author of the core implemented hardware pull-up logic in any of the core.
You'll probably have to invert those what should be normally high/active low signals coming from the core at your REU interface.
The verilog code example was for a real cart to be plugged into a real c64.
Keep the updates coming, it's really interesting seeing what you are doing.
Anyways, I will push on. I can certainly share what I have done so far if anyone wants to chip in?
Re: A matter of Bits and Cartridges.
So I eventually came to the realisation that I was effectively rewriting the existing REU code I was using to be non-tristate. And from there, I realised that the 1541 Ultimate implementation is possibly a better match. I am in the process of getting it integrated into the core now. It should make it easier to deal with the SDRAM reading/writing.
Right now, I am attempting to get the core to start up with the new REU module. Compiles are working, but getting a black screen at the moment, probably due to old active low signals being 0 now by default. My initial goal is to get the new module to handle register read and writes as per the previous module. Enabling the DMA handling should be a bit easier after that.
Right now, I am attempting to get the core to start up with the new REU module. Compiles are working, but getting a black screen at the moment, probably due to old active low signals being 0 now by default. My initial goal is to get the new module to handle register read and writes as per the previous module. Enabling the DMA handling should be a bit easier after that.
Re: A matter of Bits and Cartridges.
So good progress with the 1541 ultimate REU implementation. I was able to get it to boot (dma_n signal was defaulting to 0) and eventually got the register reads and writes working. I am now working on the transfers themselves. The 1541 code is actually a lot cleaner and bug free. It is in vhdl, so I am having to convert the format of the signals between it and the system verilog code that the top emu module uses.
Getting my head around the other REU code allowed me to get a better understanding of the whole DMA process, so it was immensely valuable. I am fixing some syntax errors currently, then will probably have to get the dma_n signal timing right. Phi2, ba, aec signals will come into that, as we have to 'pause' the dma in particular clock cycles, e.g when the VIC2 needs to access RAM or the bus.
Feel like it's getting close now.
Getting my head around the other REU code allowed me to get a better understanding of the whole DMA process, so it was immensely valuable. I am fixing some syntax errors currently, then will probably have to get the dma_n signal timing right. Phi2, ba, aec signals will come into that, as we have to 'pause' the dma in particular clock cycles, e.g when the VIC2 needs to access RAM or the bus.
Feel like it's getting close now.
Re: A matter of Bits and Cartridges.
Things are still progressing.. The Ultimate 1541 has be coaxed into working within the existing core and I am starting to see bytes being read out of c64 RAM without causing a crash. Still haven't been successful on writing them back the otherway unfortunately:
https://media.discordapp.net/attachment ... nknown.png
I am also not entirely sure about the timing of things yet. Enabling the writes causes a crash, so must have it wrong. Determining when bytes are available after the sdram reads and writes is still a bit of a mystery to me. That said, it's definitely looking more aligned now, and given some more time, I believe I will get it working.
https://media.discordapp.net/attachment ... nknown.png
I am also not entirely sure about the timing of things yet. Enabling the writes causes a crash, so must have it wrong. Determining when bytes are available after the sdram reads and writes is still a bit of a mystery to me. That said, it's definitely looking more aligned now, and given some more time, I believe I will get it working.
-
LamerDeluxe
- Top Contributor
- Posts: 1239
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 887 times
- Been thanked: 284 times
-
StatMat
- Posts: 55
- Joined: Sat Nov 14, 2020 1:19 pm
- Has thanked: 23 times
- Been thanked: 97 times
- Contact:
Re: A matter of Bits and Cartridges.
Indeed. Really nice to see trickier stuff like this tackled for the C64 core. 
Re: A matter of Bits and Cartridges.
It’s probably not that tricky for some people. But immensely educational for me. I think I found what I was doing wrong with the read write parts of my finite state machine, but will take a look at it early next week.will keep you updated. After this I want to go back to msu1 audio.
Re: A matter of Bits and Cartridges.
Here's a video updating where things are at:
https://www.youtube.com/watch?v=S-PBR4Ti1OI
Still a bit more work before I start to test on real examples:
- SDRAM memory masking - Seems that transfers to the REU are going into the same RAM that is read by the C64. Need to make sure that the location in SDRAM is out of reach of the CPU.
- Buggy transfers - sometimes the c64 bugs out after/during a transfer. I suspect I still don't have the bus muxing right with respect to DMA and writing/reading from sdram. If anyone has any suggestions on how to do this EXACTLY, please let me know. DMA in respect to the c64, not just the 652/6510. One thing I am going to try, is pausing the beginning of the transfer until Phi2 is in the correct state, as I am not entirely sure that's happening. The SuperREU project does something like this in it's bus manager. In the video, you see that the program counter changes on the REU to c64 transfer... I would have thought the PC would stay static during all transfers?
- Counts - the counts seem to be off after a transfer. This could be related to the previous point. Essentially, after a transfer, the addresses in the source and destination should be the previous addresses PLUS the total number of bytes transferred PLUS 1. Transferring data into the REU doesn't exhibit this issue, It's the transfers from REU to C64 that falters. I need to make sure that the transfer length registers are correct after a transfer as well. Currently it's getting set to #01,or two bytes. Which doesn't seem right if my original transfer is 4 bytes, right?
- Speed - I am delaying at various stages during the RACK/DACK stages of the reading and writing. Not sure on how long it takes for reads and writes to sdram, and I suspect I am delaying too much. The timing needs to be equivalent to the REU - even if I can do things faster.
- ff00 trigger - Need to detect when a write is going to FF00 and trigger REU execution appropriately.
- REU cartridge. I've chosen a monitor as the base for the REU 'cartridge'. Given that the core is running out of configuration options this seems like the best way to enable/disable the REU. Of course, I need to make sure that the cart doesn't occupy any RAM (other than the registers in df00-dfff). Once I am happy with compatibility, an additional cart will need to be constructed for distribution with the core.
Cheers,
Karl/klurman/DentNz
https://www.youtube.com/watch?v=S-PBR4Ti1OI
Still a bit more work before I start to test on real examples:
- SDRAM memory masking - Seems that transfers to the REU are going into the same RAM that is read by the C64. Need to make sure that the location in SDRAM is out of reach of the CPU.
- Buggy transfers - sometimes the c64 bugs out after/during a transfer. I suspect I still don't have the bus muxing right with respect to DMA and writing/reading from sdram. If anyone has any suggestions on how to do this EXACTLY, please let me know. DMA in respect to the c64, not just the 652/6510. One thing I am going to try, is pausing the beginning of the transfer until Phi2 is in the correct state, as I am not entirely sure that's happening. The SuperREU project does something like this in it's bus manager. In the video, you see that the program counter changes on the REU to c64 transfer... I would have thought the PC would stay static during all transfers?
- Counts - the counts seem to be off after a transfer. This could be related to the previous point. Essentially, after a transfer, the addresses in the source and destination should be the previous addresses PLUS the total number of bytes transferred PLUS 1. Transferring data into the REU doesn't exhibit this issue, It's the transfers from REU to C64 that falters. I need to make sure that the transfer length registers are correct after a transfer as well. Currently it's getting set to #01,or two bytes. Which doesn't seem right if my original transfer is 4 bytes, right?
- Speed - I am delaying at various stages during the RACK/DACK stages of the reading and writing. Not sure on how long it takes for reads and writes to sdram, and I suspect I am delaying too much. The timing needs to be equivalent to the REU - even if I can do things faster.
- ff00 trigger - Need to detect when a write is going to FF00 and trigger REU execution appropriately.
- REU cartridge. I've chosen a monitor as the base for the REU 'cartridge'. Given that the core is running out of configuration options this seems like the best way to enable/disable the REU. Of course, I need to make sure that the cart doesn't occupy any RAM (other than the registers in df00-dfff). Once I am happy with compatibility, an additional cart will need to be constructed for distribution with the core.
Cheers,
Karl/klurman/DentNz
Re: A matter of Bits and Cartridges.
SDRAM memory masking - This is now fixed. Writes to REU are out of the way of the 64k ram/rom the CPU can see. Reading back into the standard c64 area seems to work.
Counts - Seem to be fixed, albeit the length count returns to 01 still. Perhaps that's intended behavior, as it's what the Ultimate1541 REU does... Though I have read that compatibility isn't perfect with that implementation.
FF00 Trigger - This is done. Any kind of writing to this memory location will trigger an execute on the DMA transfer.
Speed - I've removed some of the delays that I addd to the code and it still seems to be functional if I allow 3 sdram operations to pass (I wait for the third sdram_ces pulse). I don't however think I am doing things right here still, see below...
Buggy transfers - Though it seems to be a lot more solid, I am STILL getting the odd crash during/after a transfer.
So I attempted to run some example REU software. The first is a basic/machine code combo that is supposed to test the REU. I've yet to disassemble the binary file to see what it is doing exactly, but suffice to say it's not working. The REU is detected and the test begins, but soon the border appears to shrink and the screen locks up. Any of the other demos appear to lock up almost immediately - albeit I have seen transfers begin, but then seem to stop.
My next line to explore is the speed/timing and trying to eliminate any further buggy transfers.
Counts - Seem to be fixed, albeit the length count returns to 01 still. Perhaps that's intended behavior, as it's what the Ultimate1541 REU does... Though I have read that compatibility isn't perfect with that implementation.
FF00 Trigger - This is done. Any kind of writing to this memory location will trigger an execute on the DMA transfer.
Speed - I've removed some of the delays that I addd to the code and it still seems to be functional if I allow 3 sdram operations to pass (I wait for the third sdram_ces pulse). I don't however think I am doing things right here still, see below...
Buggy transfers - Though it seems to be a lot more solid, I am STILL getting the odd crash during/after a transfer.
So I attempted to run some example REU software. The first is a basic/machine code combo that is supposed to test the REU. I've yet to disassemble the binary file to see what it is doing exactly, but suffice to say it's not working. The REU is detected and the test begins, but soon the border appears to shrink and the screen locks up. Any of the other demos appear to lock up almost immediately - albeit I have seen transfers begin, but then seem to stop.
My next line to explore is the speed/timing and trying to eliminate any further buggy transfers.
-
LamerDeluxe
- Top Contributor
- Posts: 1239
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 887 times
- Been thanked: 284 times
Re: A matter of Bits and Cartridges.
Sounds like you are getting really close to a version that works with existing software, that will be a really nice pay-off. Respect for all the work you've been putting into this.
Re: A matter of Bits and Cartridges.
Oh yeah, I just remembered I hadn't posted an update. Here's a video I made last Friday:
https://www.youtube.com/watch?v=xuXIE-egRrY
There's some kind of off by one error, either it's not getting ALL the bytes, or it's missing the first byte somewhere along the line. I will keep investigating.
https://www.youtube.com/watch?v=xuXIE-egRrY
There's some kind of off by one error, either it's not getting ALL the bytes, or it's missing the first byte somewhere along the line. I will keep investigating.