This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Hooloovoo
16
« on: October 17, 2015, 01:22:20 am »
Very few of us are professionals at calculator stuff, and many or most of us started off exactly where you are. What exactly do you want to learn or be able to do? If you have a specific goal in mind it will be easier to help.
Also, welcome to the forums!
17
« on: August 25, 2015, 08:12:31 pm »
All of KnightOS is opensource (including the toolchain) and can be found at https://github.com/KnightOS
The source for the emulator (z80e) can be found here: https://github.com/KnightOS/z80e
Pull requests are welcome for any part of KOS, and feel free to hang out in #knightos on the Freenode IRC server.
That is completely irrelevant and off-topic. This topic is for Jacobly's z80 emulator, and has nothing to do with KnightOS.
18
« on: August 12, 2015, 05:59:04 pm »
I think there's one of the flags (Fix n) commands which switches the function of Text(
19
« on: August 06, 2015, 11:17:50 am »
Yep, the R register is free, and you can use it for any loop which always has the same number of instructions (branching is only allowed if you're very very careful), of up to 128 loops. if you're using it for >64 loops, you need to have an odd number of instructions in your loop because of divisibility.
The I register, designed for interrupt routines is also free if IM 2 is not used, or it is saved, but is not as useful because arithmetic is not really possible, and it doesn't change by itself like R.
20
« on: August 04, 2015, 10:21:00 am »
Uuuuh, here it is that sometimes when i run it the gray is only on the left 64x64pxl box and the rightmost 16pxl column is just static o.O
I thought I had fixed this bug, which I had thought was due to LCD delay issues. The LCD is going into 6-bit mode somehow, but I'm not sure exactly how it happens. It only happens on some of my calculators, particularly the older ones, such as one of my 83+s but not the other, and my oldest 84+. EDIT: I think I have fixed it for good, and also sped it up even more by removing some of the outi's. Things are attached EDIT2: another version, fixes the same possible but unlikely LCD problem hopefully for good
21
« on: August 04, 2015, 12:29:27 am »
Here is an update which fixes a bug Runer reported and adds timer support, both for standard timers and crystal timers. Crystal timer support is there, you just need to change the define and reassemble with spasm. You will probably need to change the delay time, it should all be self-explanatory.
I tried to take a picture, but I couldn't get one to look like what I'm seeing with my eyes. I guess the answer is to run it for yourself, even though that answer sucks.
22
« on: August 02, 2015, 11:13:42 pm »
In IRC, Sorunome mentioned how he wanted to maybe do an 8-level grayscale routine for Reuben. This somehow got me thinking about one of my older projects, a 9-level grayscale routine, except this time, I wanted to optimize it far too much. So I did. Here are the results, with a demo pattern. It would look better if I put it into an interrupt routine, but I actually think it looks okay at least without. Bonus points to anyone who can figure out how it works without looking at the spoiler. Clear exits the demo program.
23
« on: July 27, 2015, 12:30:26 pm »
I believe that the sending code has a subtle timing error. I am going to do the rest of my post in code blocks because of ascii art.
When you send a bit, the lines look like this (or something similar but with things flipped):
____ ____ __
C: | | | | |
__| |____| |____|
__ ____ __
D: | | | |
|____| |_________|
? ? ? L ?
The letters under the changes in the clock are the state of the data line at that time. (L=low, H=high, ?=changing)
When the clock line changes at the same time as the data line, the receiving calc may see them at very slightly different times because the time scale here is tiny, and small errors in timing can happen.
What would be preferable is a slightly offset clock, so that the data line is certainly high or certainly low before the receiving calc sees the clock line. The slightly offset graph would look like this:
____ ____ _
C: | | | | |
____| |____| |____|
__ ____ ___
D: | | | |
|____| |_________|
L H L L H
24
« on: July 15, 2015, 12:45:35 pm »
You can only pull the lines down (I don't remember if that's a 1 or 0 in port 0 though) on the calculator side, and you should only pull the lines down on the Pi side, and leave them high otherwise. You may need a pullup resistor on the Pi though.
If you have 2 (or more) calculators, if any calculator pulls a line low by outputting to port 0, all calculators see the change, and the line doesn't go high again until all calculators let the line float.
With the way the calculator is set up, it would be pretty hard to do full-duplex transmitting anyway. Usually protocols use at least 2 wires and a ground. It's possible that we could get some kind bidirectional 1-wire interface running, one wire each way, but I don't really see the point when half-duplex is much easier and probably faster.
25
« on: July 15, 2015, 11:46:05 am »
Cool! I picked up a couple of TI link cables and connected them together for calcnet, and I also put some bare wires on them for Floppytunes and connection to other things. I soldered them together because my splicings were somewhat unreliable.
Link routines are annoying. With the way current routines work, you can only send data one direction at a time, and all kinds of other goofiness. It would be cool if we could connect the Pi's GPIO to the calc for Tilp sending though.
26
« on: April 30, 2015, 05:35:04 pm »
It's kind of ironic that I go to NN but not on the calculator team, oh well...
27
« on: February 09, 2015, 12:25:51 pm »
WE ARE NOT A SEARCH ENGINE! If you need help installing Python on windows, a simple search will get you there.
Tutorials are also not meant to be followed by typing in exactly what they say; you should read a section, experiment, and continue when you understand the section.
28
« on: February 09, 2015, 10:29:29 am »
Python is cross-platform. All of the code should be the same. Try googling if you still don't like it.
29
« on: February 08, 2015, 10:31:23 pm »
Python is more portable than C, and a C development suite is nearly impossible to install on a computer you don't own. You are making this hard for yourself and me. The forum-goers here cannot help you with programming an IRC bot in anything other than python. Everyone (to my knowlege) here who has made an IRC bot made it in python, so it is pointless to ask for help with doing it in another language. If you don't know where to look you should search something like "IRC bot C" in google and maybe that will be more helpful.
30
« on: February 08, 2015, 10:21:53 pm »
Java is not used on the web anymore. Maybe you're thinking of Javascript, which is commonly used on webpages. Javascript is not very well suited to programming bots in, though.
|
Show Posts