Looking at the memory window I finally saw some predictable changes: the value on the 1st display changed to 5- 1st keypress and then to 55 and so on.
Now I will try to "program" a sequence of keypresses which should bring me to an unsupported menu value. Wish me luck, I hope I'm getting closer.
Create an account to leave a comment. Already have an account? Log In. Hi, I'm a happy dw owner, I really like your project, but I'm not a technician, I'm only a musician. I'm disturbing you, 'cause my dw has a problem: al data is lost, I'd already changed the battery once, and recharge al the patches via tape interface.
It worked perfectly for several days. Then the DW lost the data again, if I turn it on I can hear only a long sweep, as the last time it lost the data, but now, if I turn the switch in tape ENABLE position, the display goes off and there's no way to recharge the patches.
Sorry if I ask you that, may be you can give me an advice. You seem to be an expert. Are you sure? Wow I totally missed your comment, sorry about that : You can PM me if you still need help but I bet it's overdue right now Yes, delete it Cancel.
About Us Contact Hackaday. By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies.
It can supply broadband IP to anywhere in the world and provides highly efficient, two-way satellite services for enterprises of any size. Recognizing the market need for simultaneous support for Internet and other online IP-based applications, HNS designed the DW terminal to provide users with an easy networking solution to connect multiple computers to broadband access via satellite.
The system achieves a high level of functionality with its ability to plug into a variety of external HNS appliances to support voice, legacy protocols and streaming media applications. The DW terminal delivers broadband access to one or multiple users connected to the same satellite terminal. It supports two-way connectivity between the remote units and the Internet and intranet networks.
TCP connections can be initiated to or from hosts at the remote locations. Users' intranet communications are secure and isolated from other enterprise intranets and from remotes accessing the "public" Internet operating in the same network.
I have also added the NOP instruction between latch pulses - maybe that's why it sometimes doesn't work, who knows. At least I had one free byte for my disposal :. I got back to the synthesizer of course with the old ROM, because I have nothing to write the firmware to , played with it a little bit only to confirm, that sometimes changing bank number from 2 to 3 doesn't work as it should - instead of 3 it sets 0.
Other combinations seem to work fine, so I doubt it's a timing issue I almost forgot! I know why the bank numbers were messed up after reboot - there's no SRAM battery on the mainboard! But that solves one of my problems :.
Hi there, after some struggle I've managed to get even closer to the end. What I got now is an almost working version. I have an idea why the first problem occurs, it's probably because the bank switching handler is not interrupt safe. Even if the fix looks easy to implement, I have another problem - keep reading. That would give me an opportunity to see how it behaves after reboot. Now, my biggest problem is the available memory, or lack of it.
Some time ago I said, that my plan B would be to remove tape saving and loading routines, because that's someting nobody's gonna use, especially if there's MIDI available. I think, I will remove saving to tape first, because even if there's a slightliest chance, that somebody has some old patches stored on tape or wave file, I really doubt that anybody would like to save anything back to tape No, I'm not browsing SO looking for help.
I'm experiencing it right now : After I found the definitive places where I'm going to inject my code, I noticed that my. Blah blah blah Wait a minute, I think I know why it fails. Hi there. I started writing this post because - for some strange reason - my debugger decided to crash. Not once, not twice, but all the time. I didn't quite expect this kind of behaviour, but when I loaded vanilla ROM, it was rock stable again. OK, quick look into GIT and I quickly figured out that the only change was my dreadful subroutine I created yesterday.
I needed a callable sub to be able to, well, call it from different places. The biggest limitation of the previous one was the arbitral jump into the place it should go back plus the fact, that it completely relied on values in registers. This is the old one:. The jump back was actually spot-on I figured it out after some more cumbersome code analysis , but like I said it didn't fit at all in the other place. This is what I ended up with:. First off, I'm using absolute addresses instead of values from registers.
They ain't gonna change, so I can hardcode them. And since the value I'm 'extracting' is already in bits b4-b5 and finally I'm writing it back to the upper half of PB, only one shift is necessary. Furthermore, if we store the high bit already on the 'right' position, all we need to do is to check if it's set and copy its state into our value. So far so good. But then MAME crashed a few times.
I managed to go in step mode into my routine and then I saw that the value of the vector register V is not 0x26 but 0x I was pretty sure, that the context will be right, but it turned out that I was wrong. Maybe that's why it crashed, huh? OK, let's modify it one more time:. That should do the trick. I was only concerned about the stack size, cause it's pretty tiny, but I decided to give it another go instead. Nope, still the same. I set a breakpoint on my new code again and saw that each call of my sub causes the bottommost part of the memory where the stack lives to fill with some repeating pattern.
Yup, stack overflow. That was the moment I decided to write a post, to share a laugh and maybe let my brain cool down a little bit.
0コメント