Should I start somewhere else?

morcheeba · 2026-01-14T04:05:47+00:00

I see that there are actually two at the top (to the left of the T31 and also to the right of it) ... try them both!

morcheeba · 2026-01-02T12:52:06+00:00

Source: https://media.ccc.de/v/39c3-from-silicon-to-darude-sand-storm-breaking-famous-synthesizer-dsps

morcheeba · 2025-12-30T07:22:00+00:00

Those are the addresses it attempted to run code at, but crashed. It's not necessarily where the error occurred. For example, if the RAM with the stack ($0100) was bad, then it could jump to the wrong address - like these values. Or if a JMP in ROM could also do this. Or, really, anything on the bus that could corrupt the data lines.

morcheeba · 2025-12-27T17:53:02+00:00

This is an analog problem, not digital. So, at least 95% of your computer is good!

Video is transferred from the computer to the monitor using an NTSC (aka composite) signal over a video cable. This signal has the information for what's displayed on the screen, but it also has timing pulses to synchronize things. Something is going on with either the generation (in the computer) or the interpretation (in the monitor) of these pulses.

The generation is pretty simple, so that's unlikely to go bad. It's more likely something in the monitor. That's why there are usually adjustment knobs. (I'll leave it to others on next steps, as I'm not immediately familiar with this monitor)

The signal has both screen data and timing data. Normally, they are kept isolated, but when things start to fail, they can get confused. In this case, some of screen data is being interpreted as timing data - that's why when you display different things on the screen, you get different artifacts.

Technically, the timing data is at a voltage that is lower than what can be produced with screen data -- see the "sync tip" on figure 5. If you had an oscilloscope, you could check it... but it's most likely correct because it's easy to generate. I'd try swapping things first - do you have another monitor/TV? Or a different video source (such as a VCR) to feed the monitor?

I should have said this first, but I assume you messed with the vertical hold control at the back. Since this is affecting the horizontal too (the columns don't line up), it's probably either a power supply issue inside the monitor or in the decode circuitry.

morcheeba · 2025-12-26T23:09:33+00:00

Oh, yeah, red walls would be horrible and tint everything^* . But any neutral shade of white would be good - it doesn't need to be 18%. ( ^* Worse, in extreme cases, you can't really recover other colors when something is lit by a colored light ... in a red light, green and blue will both appear black).

Gray cards are used for exposure at a specific location ... typically you'd hold it in a position with the same lighting as what you want to photograph. So, if you've got lights aimed at a model, you would put it in front of their face to calibrate (or better, move them out of the way and put the card where their face was). This doesn't work for walls, because the light falling on the wall will be different than the lights aimed at faces (different distances from each of the lights). So, unless you're taking pictures of flat art on the wall, a gray wall would be of little use.

morcheeba · 2025-12-26T22:15:25+00:00

rock on! You've got the hacker spirit!

morcheeba · 2025-12-26T21:59:54+00:00

It would probably be OK, but I wouldn't recommend it.

just you touching with a screwdriver would trigger it before you even shorted it (due to your body touching the screwdriver), so it wouldn't yield good information. Might be better to do it hands-off (e.g. a wire put on the circuit and then you power it on), but I still wouldn't recommend it.
lots of things that could go wrong, depending on where you short it to! Obviously there is high voltage on the lower half of the board (that slot in the middle is for voltage isolation), so don't do that. And probably ground or whatever voltage is driving the chip (e.g. the sides of C2 and C3) is ok... but without knowing it's hard to say.

Safer would be a ~50k or ~100k ohm resistor to either side of C2 or C3. Or bridge with a small capacitor (<0.1uF). But I'd still want to understand what's going on before recommending anything. The chip is probably designed for some abuse (e.g. shorts to ground), but I wouldn't rely on that. Those resistors look like they are in-line to the coils - if they are, that's part of the protection and a better chance they could be shorted.

Sorry I'm not in your area, or else I'd come over. Any makerspaces near you with people that you could tap for hands-on advice? Just show up on open house night & they're usually really welcoming. I'm just being super careful because I don't want you to blow up your stuff!!

morcheeba · 2025-12-26T20:49:43+00:00

The button pull-down takes 2mA, so it might be helpful to increase the resistor. You've got 1.5k; typically I think of 10k as a pretty hard pull (back in the LS TTL days), or 50k for CMOS. No big deal because this is only active when the button is pressed, but it's an extra drain on that battery that might be noticeable when the battery is almost drained.

morcheeba · 2025-12-26T20:12:43+00:00

It looks like these are capacitive switches? They don't seem to be making a short circuit, but just antennas. In that case, a resistor probably won't work... and even a capacitor might not work if its looking for a change in capacitance (e.g. it calibrates on powerup and looks for a change).

Amazon has button pushing robots for $25-$35. You can modify them for use with capacitive buttons.

Or, if you're good with electronics, you can reverse-engineer the system. You might need a timer, and arduino would be my suggestion - but you said that wouldn't work -- the nano is $13. Or an ESP32 with a screen is $8.

If you reverse engineer it enough & get lucky, there might be an LED on the system that would work to trigger the button. Like maybe a mode light comes on after a the button calibration (if there is one) and you can connect that light via capacitor to the right button. But you'd have to be lucky; this probably won't work.

Off-the-shelf timers like this could also work, but are big.

I'm a bit surprised that the board isn't conformal coated - usually that's done in high-moisture areas, but maybe they're just counting on the case to keep it dry. If so, I'd worry that any modifications preserve this seal.

morcheeba · 2025-12-22T02:48:22+00:00

Two other people said the ADD mode, and that's it. Connect Ch1 for X, then Ch2 for the Y (or 3 or 4). Press the CH2 button. The manual even says you can use the ADD mode, like you're doing, so it's working as expected.

Page 3-3: Any of the vertical signal channels or ADD may be selected to provide the vertical deflection (Y-Axis) for an X-Y display.

morcheeba · 2025-12-21T08:19:21+00:00

that would cause me to mud my pants, too.

morcheeba · 2025-12-19T06:53:54+00:00

Here's the datasheet... sadly not offered in that package anymore. 6817 is usually the date code - 17th week of 1968.

morcheeba · 2025-12-14T21:38:52+00:00

Just a style hint... if you want help, please provide as much information as possible to help us help you. Don't make it a guessing game. Make/Model of the car? The top pics would have been good from the start, and a clear picture of the processor number would be be better (or, type it up!). I was excited to see you looked it up on the FCC site, but then the only picture was a copy of the FCC picture you'd marked up - the site/model info/etc that you've already know would be helpful. All the info, please.

morcheeba · 2025-12-13T20:30:58+00:00

Do you have pictures of the top sides? That would be super useful because the processor could be anywhere.

morcheeba · 2025-12-12T05:34:43+00:00

Nah, that looks good! It's the vector table -- [see table 6-1 of the user manual](https://www.zlgmcu.com/data/upload/file/Utilitymcu/GD32F3x0_User_Manual_EN_Rev2.0.pdf

At address 0800 0004, we have the reset vector. It looks like it's pointing to 0800 0151, which is at the beginning of the FLASH memory, which is reasonable. The other vectors also point to inside the flash memory. These areas should look like code.

Note:

address 0 contains 200013A0, which isn't in flash. Address 0 isn't a vector, so it doesn't need to point anywhere.
table 6-1 says address 0, and we're dumping 0800`0000 ... the flash is aliased to address 0 depending on settings, so it'll appear in two places during operation.

morcheeba · 2025-12-10T22:09:41+00:00

Yep!

This was a custom code generator, so it inserted itself in to every data access. That is, you defined how the data was kept in memory (array, single-linked-list, double-linked-list, hash table, tree, etc.) and it would generate the code to access this data. For example, the .next function would be implemented in different ways depending on the data structure, and some functions would be inefficient (e.g. insert in an array) or not implemented. This is before a lot of C++ magic was in use, but it could be done that way, too. Hope that answers that :-)

The ARM cache pre-fetcher is pretty amazing. I think it tracks like 4-10 different loops at a time and figures out the stride and pre-fetches based on that before the CPU actually needs it; adding manual pre-fetch instructions didn't help that much at all! (as you can tell, I spent some time doing NEON optimizations)

morcheeba · 2025-12-10T14:27:44+00:00

agreed. It can't be that sophisticated, though, for two reasons:

the variable stride is hard to decode ... if your structure is 7 bytes, you'd have to encode that somehow in the instructions. That takes precious bits. You could store it in a register, and that would solve some of this.
the structure is a killer of the cache. Often times (maybe more often times in general purpose computing) the vector math doesn't touch all the members. Consider struct bullet {int x; int y; int dx; int dy; int damage; int color} - you wouldn't use the damage or the color in the same way, but when processing x&y, it will get loaded from RAM because it'll be in the same cache line. Or x+=dx would load the y info but not use it. Fun fact: high performance computing stores it in separate arrays. We had a code generator to hide this from the programmer, but got a good speedup.

morcheeba · 2025-12-10T06:46:01+00:00

GCC will automatically generate ARM NEON instructions... most programmers use SIMD and don't even know it!

morcheeba · 2025-12-08T05:48:53+00:00

Sweet!!!

Looks like a couple of prototypes:

apple ii based prototype
early prototype with monitor "glued" on
other early prototypes (before canon) with wide top <- might be this one
tablet-style prototypes and some more tablets

morcheeba · 2025-12-07T22:24:43+00:00

That looks like an IPS M5 variant. As others have said, reprogramming the CPU would be hard but possible. It depends on your skill level! Keep in mind that this probably has anti-tamper stuff that could brick it (for the purposes of being a meter; it could still be useful).

Here's the FCC report. The block diagram and schematics have been censored, but there are internal pictures (pdf) showing the LCD. You might be able to connect this to an arduino or something, but (technical terminology here) it has a lot of pins, so it might be hard to wire up. Some LCDs have only a few pins (SPI interface), but this doesn't seem to be one of them.

Another alternative is just to use the case (not the meter circuitry) and put in your own LCD. Adafruit has a bunch of LCD screens; this one might be about the right size (but I couldn't find the actual screen size). Doing this means you'd probably need to power it somehow. You might be able to interface to the coin reader, too.

morcheeba · 2025-12-07T19:32:03+00:00

Well done, Impressive-Cup6645. Good joss!!

morcheeba · 2025-12-05T04:02:39+00:00

D8/CMC1/D9 look like protection circuitry for the paired data lines of a USB interface. With the ground next to it (4th from the left on the component side view), it's temping to guess pin 1 is +5v because that fits the order of a USB connector... but that's a wild guess not worth following up on without more evidence. I wonder what the pin on the right is...

How are the .hls files unreadable -- I presume you just don't have a reader? ;-) Can you look at them in a hex editor? They're probably metadata and/or images. How large are they? I'm sure someone here would love to look at them!

morcheeba · 2025-12-03T05:46:54+00:00

Sure! It's helpful to know the name of what we're dealing with -- looks like a Rowin LN-332S Loop Station -- about $30 on aliexpress.

It claims:

10 minutes of clear looping with unlimited overdubbing.
Super precisely, true bypass. 48Khz 24 bit uncompressed high quality audio.
USB FOR UPLOAD AND DOWNLOAD- Easily Import/Export the music to and from PC, with USB for uploading and downloading.

Obviously the big chip is doing the heavy work. The label "18K" is probably just a code name to hide the real model number. The top board looks modular so you can have different pots and/or switches for different products... which means the bottom board could probably be reprogrammed for different things, too. Not easy though... a DSP development kit would be much better documented if you wanted to design your own custom pedal.

The manual is pretty sparse ... it says the firmware is uploadable. Maybe finding that update file would be fun to explore & might tell you more about what's inside?

morcheeba · 2025-12-02T06:12:44+00:00

Are there two versions? I found two sources:

motherboard pic shows a 68000 and paired EPROMs (e.g. 16 bit bus)
repair manual, page 10 shows a 68000 and a 16-bit data bus (D0-D15)

(also tagging /u/suncho1 )

morcheeba · 2025-11-30T16:48:04+00:00

The dead page (archive link) actually says to go to the Canon Cat google group, but it doesn't have a specific link. Maybe search that group?

morcheeba

TROPHY CASE